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

[Bodo Eggert]

On Mon, 23 Jul 2007, Rob Landley wrote:
> On Saturday 21 July 2007 8:14:41 am Bodo Eggert wrote:
> > Greg KH <greg@xxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/