Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030263AbWBNKkH (ORCPT ); Tue, 14 Feb 2006 05:40:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030558AbWBNKkG (ORCPT ); Tue, 14 Feb 2006 05:40:06 -0500 Received: from dspnet.fr.eu.org ([213.186.44.138]:27147 "EHLO dspnet.fr.eu.org") by vger.kernel.org with ESMTP id S1030263AbWBNKkF (ORCPT ); Tue, 14 Feb 2006 05:40:05 -0500 Date: Tue, 14 Feb 2006 11:40:04 +0100 From: Olivier Galibert To: ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com Cc: Greg KH , linux-kernel@vger.kernel.org Subject: Re: Device enumeration (was Re: CD writing in future Linux (stirring up a hornets' nest)) Message-ID: <20060214104003.GA97714@dspnet.fr.eu.org> Mail-Followup-To: Olivier Galibert , ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com, Greg KH , linux-kernel@vger.kernel.org References: <43D7C1DF.1070606@gmx.de> <20060213175046.GA20952@kroah.com> <20060213195322.GB89006@dspnet.fr.eu.org> <200602140023.15771.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602140023.15771.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3516 Lines: 81 On Tue, Feb 14, 2006 at 12:23:15AM -0500, Andrew James Wade wrote: > 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. Indeed. > The difficulty is the mapping between sysfs and /dev. Which is what I say each time. > That mapping should not live in sysfs, > /dev is none of the kernel's business and sysfs is the kernel's playground. Why not have udev and whatever comes after tell the kernel so that a symlink is done in sysfs? The kernel not deciding policy do not prevent it from storing and giving back userland-provided information. You get the best of both worlds, complete device information including how to talk with it in sysfs, and complete naming and policy setting in userspace. > > 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 Why manage a directory tree in udev when you have a perfectly good one in sysfs already. We're talking about a friggin' userland-provided string here, nothing more. > But I don't know if there is much point in doing so as udev already > provides that information. I guess you didn't bother to read the "answer 3" paragraph of my email. Do you trust udev to still exist two years from now, given that hotplug died in less than that? Do you trust udevinfo to have the same interface two years from now given that the current interface is already incompatible with a not even two-years old one (udev 039, 15-Oct-2004 according to kernel.org) which is widely deployed as part of fedora core 3? Of course I can always go the ALSA way, hardcode the device names and tell udev (and the user) to fuck off. OG. - 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/