Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030455AbWBNFXl (ORCPT ); Tue, 14 Feb 2006 00:23:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030463AbWBNFXk (ORCPT ); Tue, 14 Feb 2006 00:23:40 -0500 Received: from xproxy.gmail.com ([66.249.82.198]:10508 "EHLO xproxy.gmail.com") by vger.kernel.org with ESMTP id S1030461AbWBNFXh (ORCPT ); Tue, 14 Feb 2006 00:23:37 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=E66FTru50kRJehDhXsBjVDziayw92Pb9lpo71GTJrwrmg4abNjE6sd86X7mkeWO/E8BicUK43/HguwdVDXNPPCKSR21oWTcChLrK5iw11H/nzegAO/m/Q+8tlGL2huKCPITlkpGulpWA+yswCDG7rR1G2DeuJBwm34vTtFfXybs= Reply-To: ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com To: Olivier Galibert Subject: Re: Device enumeration (was Re: CD writing in future Linux (stirring up a hornets' nest)) Date: Tue, 14 Feb 2006 00:23:15 -0500 User-Agent: KMail/1.8.3 Cc: Greg KH , linux-kernel@vger.kernel.org References: <43D7C1DF.1070606@gmx.de> <20060213175046.GA20952@kroah.com> <20060213195322.GB89006@dspnet.fr.eu.org> In-Reply-To: <20060213195322.GB89006@dspnet.fr.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602140023.15771.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com> From: Andrew James Wade Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2268 Lines: 47 On Monday 13 February 2006 14:53, Olivier Galibert wrote: > Problem: finding and talking to all the devices which have capability > , as long as the system administrator allows. ... > At that point, we get several answers: ... > 4- sysfs has all the information you need, just read it ... > Answer 4 would be very nice if it was correct. sysfs is pretty much > mandatory at that point, and modulo some fixable incompleteness > provides all the capability information and model names and everything > needed to find the useful devices. What it does not provide is the > mapping between a device as found in sysfs, and a device node you can > open to talk to the device. You get the major/minor, which allows you > to create a temporary device node iff you're root. Or you can scan > all the nodes in /dev to find the one to open, which is kinda > ridiculous and inefficient. Or you have to go back to udev/hal to ask > for the sysfs node/device node path mapping, and then why use sysfs in > the first place. They're providing different things. Enumerating devices (as the kernel sees them) is sysfs's business. Providing device nodes is not the kernel's business, and should not be. (The kernel doesn't know the appropriate permissions). And while it can be used to enumerate devices, that's not really the function of /dev. It's providing the device nodes with the appropriate permissions, and hopefully with names that are meaningful to the users. So you really need both sysfs and /dev. The difficulty is the mapping between sysfs and /dev. That mapping should not live in sysfs, /dev is none of the kernel's business and sysfs is the kernel's playground. The mapping could be provided via symlinks, like so: /dev/rdev/block/hdb/hdb1 -> /dev/hdb1 /dev/rdev/block/hdb -> /dev/hdb /dev/rdev/block/hda/hda2 -> /dev/hda2 /dev/rdev/block/hda/hda1 -> /dev/hda1 /dev/rdev/block/hda -> /dev/hda ... But I don't know if there is much point in doing so as udev already provides that information. Andrew Wade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/