Device Registry (DevReg) Patch 0.2.0

Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

The Linux Device Registry (devreg) is a kernel patch that adds a device 
database in XML format to the /proc filesystem. It collects all information 
about the system's physical devices, creates persistent device ids and 
provides them in the file /proc/devreg.

Devreg has three purposes:
- collect all configuration data from drivers so the user can browse his 
hardware configuration. 
-allow an application to display all devices that provide a certain interface 
(for example all mice) so the user can chose one. 
-allow an application to find the device that the user has selected after a 
reboot or a hotplug action: the device files in /dev do not offer stable 
names, they depend on the order in that the devices have been plugged in or 
powered on. 

Changes since last release (0.1.1):
- converted file format to XML
- bus-specific information from pci and usb added
- fixed locking

The patch (for 2.4.3) can be found at 
http://www.tjansen.de/devreg/devreg-2.4.3-0.2.0.diff.gz
To test it, apply the patch, select CONFIG_DEVFS_FS and CONFIG_DEVREG and 
compile. Note that the patch will break binary drivers.

Supported hardware in version 0.2.0: PCI subsystem, USB subsystem, most PCI 
sound cards, USB HID devices, USB hubs, USB printers

Other information and a user-space library can be found at 
http://www.tjansen.de/devreg

Re: Device Registry (DevReg) Patch 0.2.0

[Martin Dalecki]

Tim Jansen wrote:
> 
> The Linux Device Registry (devreg) is a kernel patch that adds a device
> database in XML format to the /proc filesystem. It collects all information
OH SHIT!!     ^^^ 

<IRONY>
Why don't you just add postscript output to /proc?
</IRONY>

> about the system's physical devices, creates persistent device ids and
> provides them in the file /proc/devreg.

Re: Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> Tim Jansen wrote:
> > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > database in XML format to the /proc filesystem. It collects all
> OH SHIT!!      ^^^
> Why don't you just add postscript output to /proc?

XML wasn't my first choice. The 0.1.x versions used simple name/value pairs, 
I gave this up after trying to fit the complex USB 
configuration/interface/endpoint data into name/value pairs. Thinking about 
text file formats that allow me to display hierarchical information,  XML was 
the obvious choice for me. Are there alternatives to get complex and 
extendable information out to user space? (see 
http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg 
output)
My other ideas were:
- using a simple binary format, just dump structs. This would break all 
applications every time somebody changes the format, and this should happen 
very often because of the nature of the format
- using a complicated, extendable binary format, for example chunk-based like 
(a|r)iff file formats. This would add more code in the kernel than XML 
output, is difficult to understand and requires more work in user space 
(because XML parsers are already available)
- making up a new text-based format with properties similar to XML because I 
knew that many people dont like the idea of XML output in the kernel.. I 
really thought about it, but it does not make much sense.

The actual code overhead of XML output compared to a format like 
/proc/bus/usb/devices is almost zero, XML is only a little bit more verbose. 
I agree that XML is not perfect for this kind of data, but it is simple to 
generate, well known and I dont see a better alternative. 

bye..
 

Re: Device Registry (DevReg) Patch 0.2.0

[Martin Dalecki]

Tim Jansen wrote:
> 
> On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> > Tim Jansen wrote:
> > > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!!      ^^^
> > Why don't you just add postscript output to /proc?
> 
> XML wasn't my first choice. The 0.1.x versions used simple name/value pairs,
> I gave this up after trying to fit the complex USB
> configuration/interface/endpoint data into name/value pairs. Thinking about
> text file formats that allow me to display hierarchical information,  XML was
> the obvious choice for me. Are there alternatives to get complex and
> extendable information out to user space? (see
> http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg
> output)

Yes filesystem structures. Or just simple parsing in the user space
plain binary
data.

> My other ideas were:
> - using a simple binary format, just dump structs. This would break all
> applications every time somebody changes the format, and this should happen
> very often because of the nature of the format
> - using a complicated, extendable binary format, for example chunk-based like
> (a|r)iff file formats. This would add more code in the kernel than XML
> output, is difficult to understand and requires more work in user space
> (because XML parsers are already available)
> - making up a new text-based format with properties similar to XML because I
> knew that many people dont like the idea of XML output in the kernel.. I
> really thought about it, but it does not make much sense.
> 
> The actual code overhead of XML output compared to a format like
> /proc/bus/usb/devices is almost zero, XML is only a little bit more verbose.
> I agree that XML is not perfect for this kind of data, but it is simple to
> generate, well known and I dont see a better alternative.
> 
> bye..
> 
> -
> 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/

-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R

Re: Device Registry (DevReg) Patch 0.2.0

[mirabilos]

> > > The Linux Device Registry (devreg) is a kernel patch that adds a
device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!!      ^^^
> > Why don't you just add postscript output to /proc?
>
> XML wasn't my first choice. The 0.1.x versions used simple name/value
pairs,
> I gave this up after trying to fit the complex USB
> configuration/interface/endpoint data into name/value pairs. Thinking
about
> text file formats that allow me to display hierarchical information,
XML was
> the obvious choice for me. Are there alternatives to get complex and
> extendable information out to user space? (see
> http://www.tjansen.de/devreg/devreg.output.txt for a example
/proc/devreg
> output)
> My other ideas were:
> - using a simple binary format, just dump structs. This would break
all
> applications every time somebody changes the format, and this should
happen
> very often because of the nature of the format
> - using a complicated, extendable binary format, for example
chunk-based like
> (a|r)iff file formats. This would add more code in the kernel than XML
> output, is difficult to understand and requires more work in user
space
> (because XML parsers are already available)
> - making up a new text-based format with properties similar to XML
because I
> knew that many people dont like the idea of XML output in the kernel..
I
> really thought about it, but it does not make much sense.

What about indenting? I think of 0 spaces before the device name,
1 space before properties which belong to the device. (Is one level
enough? I'm currently offline so didn't check the sample)
Structure per entry:
   [Space] Name colon property
It also could be an equality sign, but then we could use no
indention at all and [] for the sections, which leaves us
at .INI format, which after all still is lotta more readable after
cat than XML.

> The actual code overhead of XML output compared to a format like
> /proc/bus/usb/devices is almost zero, XML is only a little bit more
verbose.
> I agree that XML is not perfect for this kind of data, but it is
simple to
> generate, well known and I dont see a better alternative.
>
> bye..

-mirabilos

Re: Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

On Tuesday 24 April 2001 18:39, Martin Dalecki wrote:
> Are there alternatives to get complex and extendable information out to 
> user space?
> Yes filesystem structures. 


How exactly can this work? A single value per file is not very helpful if you 
have a thousand values. You could cluster them (for example one level in the 
XML hierarchy == one file), but this will soon get very complicated. Its much 
more work to implement in the kernel, its painful in user-space and you cant 
just use a text editor to look at it (because you always have to look at 10 
files per device). 
IMHO only a single XML file per physical device is an option, but I do not 
know how to name the files...


> Or just simple parsing in the user space plain binary data.

This would be a compatibility nightmare and hard to maintain. Once you 
decided for a binary format you cannot change or extend it without breaking 
user-space apps. This may save a few lines code, but not many. All you need 
to add a line to XML output is a sprintf and a call to devreg_write_line(). 

One of the ideas of devreg is that while it has a common format for generic 
information, like the name and topology of physical devices, every driver can 
add additional data (this is why XML namespaces are used). Currently only the 
USB and PCI subsystems add data to devreg, but in future versions the device 
driver itself or other subsystems should do this, too. 

bye...

Re: Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

On Tuesday 24 April 2001 18:43, mirabilos wrote:
> What about indenting? I think of 0 spaces before the device name,
> 1 space before properties which belong to the device. 
> Structure per entry:
>    [Space] Name colon property

But what is the advantage? Its not less work in the kernel, and in user-space 
you need to write a parser for this. You would have made a new format for 
hierarchical data that no one else uses only to avoid using XML in the 
kernel. 


> Is one level enough? I'm currently offline so didn't check the sample

No, for example for USB you have the levels 
devices/configurations/interfaces/endpoints. 

bye...

Re: Device Registry (DevReg) Patch 0.2.0

[H. Peter Anvin]

Followup to:  <3AE704FA.DCF1BEC6@kegel.com>
By author:    Dan Kegel <dank@kegel.com>
In newsgroup: linux.dev.kernel
> 
> The only problem with /proc as it stands is that there is no formal
> syntax for its entries.  Some of them are hard to parse.
> 

/proc/sys is probably the method to follow.  Every item is a datum of
a simple datatype.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Device Registry (DevReg) Patch 0.2.0

[Dan Kegel]

Tim Jansen wrote:
> On Tuesday 24 April 2001 18:39, Martin Dalecki wrote: 
> >> Are there alternatives to get complex and extendable information out to 
> >> user space? 
> > Yes filesystem structures. 
> 
> How exactly can this work? A single value per file is not very helpful if you 
> have a thousand values. You could cluster them (for example one level in the 
> XML hierarchy == one file), but this will soon get very complicated. Its much 
> more work to implement in the kernel, its painful in user-space and you cant 
> just use a text editor to look at it (because you always have to look at 10 
> files per device). 

The command
  more foo/* foo/*/* 
will display the values in the foo subtree nicely, I think.

Think of the /proc tree as the XML parse tree already exploded for you.

The only problem with /proc as it stands is that there is no formal
syntax for its entries.  Some of them are hard to parse.

Before we add a new /proc entry that generates XML which summarizes
the rest of /proc, it might make sense to standardize /proc entries
and write a regression test to verify they are formatted correctly.
It would then be trivial to write a /proc to XML converter which
ran solely in userspace.

See 
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.0/0506.html
and
http://marc.theaimsgroup.com/?l=linux-kernel&s=%2Fproc+xml

for prior discussion on the matter.

I don't want to dismiss the reasons you want to use XML for this,
but tread carefully, lest you duplicate lots of code and introduce
cruft.  Better to factor the XML part out to a userspace library...

- Dan