Re: [RFC/Patch] Device Registry

Re: [RFC/Patch] Device Registry

[David Brownell]

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

Re: [RFC/Patch] Device Registry

[Tim Jansen]

On Sunday 01 April 2001 19:47, you wrote:
> 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.

>     - The "Device IDs", if they're unique enough,
>       remove need for a "common/number" attribute.

Agreed.

>     - 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.


>     - 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC/Patch] Device Registry

[Tim Jansen]

On Sunday 01 April 2001 19:47, you wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel