Device Registry
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · you
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.
I am very interested in ideas how to do this better (especially to have one file per device), but there were three reasons for the current implementation:
- it is easier to implement in kernel and user-space
- i dont know how to name the devices. I looked at the way sun did it with their device tree and didnt like it, even though I like the everything-is-a-file notion, too
- as you said, it is important to be able to find all devices in the system. Actually this was my orginal intent, I wanted to get all possible information about all devices and display them to the user.
Quoted 2 lines
- The "Device IDs", if they're unique enough, remove need for a "common/number" attribute.
Agreed.
Quoted 4 lines
- 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.
The reason for vendor/product ID and serial number is that you should not be forced to reconfigure your system when you plug your device in another slot or hub. I think this is a desirable goal.
Quoted 4 lines
- 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.
Yes, this is why there are sub-devices. Each function should be displayed as a sub-device. I just haven't implemented this yet.
BTW: don't try the patch version 0.0.1 unless have CONFIG_SMP turned off and compile USB support into the kernel, otherwise it will not work. I hope to make the next release tomorrow...
bye...
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · you
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).
Thinking about this for the last few days, I think it was a mistake to use name/value pairs. One of the ideas of devreg was to replace all these files like /proc/pci, /proc/bus/usb/devices (or their binary, non-deprecated equivalents) with a single file, but it is not possible to make complex lists with name/value pairs. For example they cannot be used to list all endpoints of an USB interface.
I need a more complex format for that, and the obvious choice would be XML. The idea of using XML in the kernel seems weird to me, but as long as you only write it there is no overhead compared to other solutions. Using tools like grep is a problem though. even they are still usable as long as the layout is grep-friendly (elements and their content on the same line and so on).
I'd like to get some opinions about that and maybe alternatives...
bye...
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel