From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Sun, 01 Apr 2001 17:47:11 +0000 Subject: Re: [RFC/Patch] Device Registry Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org I've just started to wrap my head around the approach in http://www.tjansen.de/devreg and how it might get used. A one sentence summary: this registry is a text file in a new format, presenting a logically flat namespace of devices each with descriptive {attribute-name,value} pairs (X.500-ish). I like the notion of modeling through attributes, but the flat namespace bothers me a lot. Except maybe as a way to finesse the namespace structure arguments! I'd rather see separate naming contexts (directories) grouping different types of devices. Disk storage, network interfaces, printers, and so on. Sure, use a common root so apps can use ftw() to make sure they find all the relevant devices. Also, it seems to me there's some overlap with the "scsimon" work (see the linux-hotplug links page), which I understand has relations to similar IDE-focussed work. But to pick on the specific device attributes for a moment, here are a few comments: - The "Device IDs", if they're unique enough, remove need for a "common/number" attribute. - Physical topology is a much better way to derive the device ids ... in fact, likely the only way that can work in general. Vendor/product IDs don't belong there, or even device type/class codes. - For PCI, "device" isn't the right focus, it's the "function" -- devices can have many functions, not necessarily related. /proc/bus/pci/* has per-function files. - Similarly for USB, "device" isn't the right focus but "interface" (in a given configuration). This is something that /proc/bus/usb does wrong, IMO (but it's "preliminary", no worries yet). After seeing the preliminary reportage of the hotplug discussions at the kernel summit, I anticipate many further fruitful (and likely not-so-fruitful :) debates about naming and hotplugging. It's pretty fundamental to taking a systems approach to this stuff. I hope those debates will continue to use device attributes when they model the information that's provided, since that's a good way to start focussing on the common notions that underly the various application and kernel issues ... without arguing about implementation details like how to expose that information (tree structure, flat file, ioctl, etc). - Dave _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel