Re: Documentation for sysfs, hotplug, and firmware loading.

Bodo Eggert
2007-08-05T12:57:58Z

On Mon, 23 Jul 2007, Rob Landley wrote:
> On Saturday 21 July 2007 8:14:41 am Bodo Eggert wrote:
> > Greg KH <greg@kroah.com> wrote:
> > > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote:
> > >> I'm not trying to document /sys/devices. I'm trying to document
> > >> hotplug, populating /dev, and things like firmware loading that fall out
> > >> of that. This requires use of sysfs, and I'm only trying to document as
> > >> much of sysfs as you need to do that.
> > >
> > > Like I stated before, you do not need to even have sysfs mounted to have
> > > a dynamic /dev.
> > >
> > > And why do you need to document populating /dev dynamically? udev
> > > already solves this problem for you, it's not like people are going off
> > > and reinventing udev for their own enjoyment would not at least look at
> > > how it solves this problem first.
> >
> > Turning your words around, you get: "Whatever one of these programs does
> > documents how dynamic devices should be handled." If this is true, any
> > change that makes one of these programs break is a kernel bug.
> >
> > Besides that: How am I supposed to be able to correctly change udev if
> > there is no document telling me what would work and what happens to
> > work by accident?
>
> You aren't expected to. Remember that udev and sysfs are written by the same
> people, working together off-list. They're free to break the exported data
> format on a whim, because they write the code at both ends and fundamentally
> they're talking to themselves. They honestly say you can't expect a new
> kernel to work with an old udev, and they say it with a straight face. (To
> me, this sounds like saying you can't expect a new kernel to work with an old
> version of ps, because of /proc.)
>
> Documentation is a threat to this way of working, because it would impose
> restrictions on them. A spec is only of use if you introduce the radical
> idea that the information exported by sysfs exists for some purpose _other_
> than simply to provide udev with information (and a specific version of udev
> matched to that kernel version, at that).

And having no documentation is, as you can see in this thread, a threat to
open software. Having exactly one blob of software, and being left on your
own once you change a bit, is one step away from having a binary only module.

> > > To do otherwise would be foolish :)
> >
> > Some people like to fool around and create even smaller wheels.
> > E.g. I'm changing the ACPI button driver to just call Ctrl_alt_del
> > in order not to have an extra process running and free 0.2 % of my RAM.
>
> When I started looking at udev in 2005, it was a disaster. My commentary at
> the time is at http://lkml.org/lkml/2005/10/30/189 and the relevant bit is:

[...]

> And so I made mdev, a utility which populated /dev _with_ a config file in 7k.
> Greg's upset I didn't just patch udev to remove libsysfs, remove the
> duplicated klibc code, remove the gratuitous database, remove the
> overcomplicated config file parser (with rules compiler), and so on. They're
> boggling that I could ever have been unhappy with the One True Project to
> populate /dev.

I see, we agree on this point. Besides that, I like to see the steps to be
done, instead of having a letter sent to a voodoo doctor in Africa (called
udev) and getting back a magic spell to be chanted on my system (unless
he just pokes some voodoo doll).
--
Top 100 things you don't want the sysadmin to say:
87. Sorry, the new equipment didn't get budgetted.