Message-Id: <E1ICDr7-0000e9-P4@be1.lrz>
Date:	Sat, 21 Jul 2007 14:14:41 +0200
From:	Bodo Eggert <7eggert@....de>
To:	Greg KH <greg@...ah.com>, Rob Landley <rob@...dley.net>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel@...r.kernel.org, Michael-Luke Jones <mlj28@....ac.uk>,
	Krzysztof Halasa <khc@...waw.pl>,
	Rod Whitby <rod@...tby.id.au>,
	Russell King <rmk@....linux.org.uk>, david@...g.hm
Subject: Re: Documentation for sysfs, hotplug, and firmware loading.

Greg KH <greg@...ah.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?

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

> Firmware loading is fine to document if you wish to do so.  But again,
> why?  We already have multiple userspace programs that provide this
> feature for them.  Perhaps you want to document how to add firmware to a
> system in order for these different programs to pick them up?

I once tried to install a firmware for hotplug. Even finding the place whre
I'm supposed to put it was harder than rewriting that *beep* from start,
but I could not rewrite it because I didn't have any documentation.
Even digging in that pile of wrapper scrips in order to debug that thing
was a nightmare. (Having a number of places where the firmware will be
expected in one of many versions and formats stored using one of many
filenames can drive you nuts.)

> Or perhaps you want to document how to add this kind of functionality to
> your kernel driver so that it can handle firmware loading by using the
> firmware interface that the kernel provides?

I suppose that's missing, too. Or scattered in a number of contradicting
and mostly outdated howtos across the internet.

> If you just want to document the hotplug/uevent api, then do just that.
> However I think you are overreaching with your scope here and getting
> mighty confused in the process.

In other words: Grasping sysfs is not a feasible task? If this is true,
how can anybody reliably use sysfs?
-- 
Top 100 things you don't want the sysadmin to say:
99. Shit!!

Friß, Spammer: G@...eggert.dyndns.org Sln3@...7eggert.dyndns.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists