On Mon, 23 Jul 2007, Rob Landley wrote: > On Saturday 21 July 2007 8:14:41 am Bodo Eggert wrote: > > Greg KH <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
