From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 04 Jun 2002 19:00:10 +0000 Subject: Re: Which node has the device been bound to? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org >>>Then use the device tree in driverfs as a "hint" as to where you might >>>find your device. Then rely on other things (fs labels, usb serial >>>numbers, ethernet mac addresses, etc.) to verify if the device you are >>>talking to really is the one you think it is. FWIW I do think it'd be worth making it easier (in 2.5) for drivers to use stable physical device IDs ... since those are the only IDs that always exist. Not every device has a unique label (FS, MAC, serial, etc), but even given hotplugging, at a given moment a given physical/topological ID refers to only one device. We have such IDs already, in most subsystems. What we don't have is ways to go from physical ID to logical (char/block major+minor, or whatever) IDs, and back. Historically, that kind of thing has always been done using ioctls on open files. Defining such IOCTLs, and teaching the various driver frameworks to use them, has no particular technical challenges. (Politics may be a different issue. Easier for each subsystem to have its own ioctls -- like ethtool -- than unify all drivers...) >>The project started out to solve the problem once and forever and now we >>are back at several heuristics. > > Wait, what project? linux-hotplug was created to "solve" the initial > problem of people calling /sbin/hotplug in different ways, which broke > userspace tools. It then became a forum for the linux-hotplug package, > and general hotplugging issues. > > It was never created to solve "the hotplugging/device naming/persistent > path/fish slicing and dicing" problem. On the other hand, the hotplug framework certainly does need to have some solution to the "hands-off no-adminstrator configuration" problems to meet its basic usability goals (except some parts of enterprise configurations). That is, while I agree that the problem isn't just a hotplugging issue (hotplugging wasn't created to solve that) I don't agreee with the implication that it's even slightly offtopic. (Part of this is actually "device discovery": finding out what CDs, cameras, mice, etc are connected. Another part is "device announcement", a level up from loading the right driver module: configuring that printer or network link, mounting disk partitions, and so on.) > Just because we can't uniquely, and race-free identify a device node > with a physical device (either mapping, you choose) doesn't mean all is > lost. We've never been able to do that :) Hardly! On the other hand, that's always been a bug from the perspective of being able to do hands-off configuration. Call it an RFE if you want, but that kind of capability is essential for broader uses of Linux: we can't expect every K-12 or home user to be (or have access) to a Linux sysadmin, and we know the "every vendor does their own sysadmin tools" approach doesn't work, just from seeing it fail so thoroughly for all the classic UNIX vendors. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel