From: Bodo Eggert <7eggert@gmx.de>
To: Greg KH <greg@kroah.com>, Rob Landley <rob@landley.net>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
linux-kernel@vger.kernel.org,
Michael-Luke Jones <mlj28@cam.ac.uk>,
Krzysztof Halasa <khc@pm.waw.pl>, Rod Whitby <rod@whitby.id.au>,
Russell King <rmk@arm.linux.org.uk>,
david@lang.hm
Subject: Re: Documentation for sysfs, hotplug, and firmware loading.
Date: Sat, 21 Jul 2007 14:14:41 +0200 [thread overview]
Message-ID: <E1ICDr7-0000e9-P4@be1.lrz> (raw)
In-Reply-To: 8Jbuh-84N-3@gated-at.bofh.it
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?
> 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@r.7eggert.dyndns.org Sln3@hI.7eggert.dyndns.org
next parent reply other threads:[~2007-07-21 12:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8I2t1-7jt-5@gated-at.bofh.it>
[not found] ` <8IlPa-3Gl-61@gated-at.bofh.it>
[not found] ` <8IzyM-86P-47@gated-at.bofh.it>
[not found] ` <8Jb1c-7vL-3@gated-at.bofh.it>
[not found] ` <8Jbuh-84N-3@gated-at.bofh.it>
2007-07-21 12:14 ` Bodo Eggert [this message]
2007-07-23 21:49 ` Documentation for sysfs, hotplug, and firmware loading Rob Landley
2007-08-05 12:57 ` Bodo Eggert
2007-07-24 6:38 ` Greg KH
2007-07-25 19:28 ` Rob Landley
2007-07-17 21:03 Rob Landley
2007-07-17 21:55 ` Randy Dunlap
2007-07-18 7:58 ` Cornelia Huck
2007-07-18 17:39 ` Rob Landley
2007-07-18 23:33 ` Kay Sievers
2007-07-20 5:14 ` Rob Landley
2007-07-20 7:00 ` Greg KH
2007-07-20 7:54 ` Cornelia Huck
2007-07-20 8:09 ` Greg KH
2007-07-21 3:48 ` Rob Landley
2007-07-21 6:23 ` Rob Landley
2007-07-18 23:40 ` Greg KH
2007-07-21 0:37 ` Rob Landley
2007-07-19 8:16 ` Cornelia Huck
2007-07-21 0:21 ` Rob Landley
2007-07-21 0:43 ` Greg KH
2007-07-23 23:26 ` Rob Landley
2007-07-24 7:38 ` Cornelia Huck
2007-07-21 0:49 ` Greg KH
2007-07-21 0:52 ` Greg KH
2007-07-21 6:32 ` Rob Landley
2007-07-18 10:33 ` Kay Sievers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1ICDr7-0000e9-P4@be1.lrz \
--to=7eggert@gmx.de \
--cc=cornelia.huck@de.ibm.com \
--cc=david@lang.hm \
--cc=greg@kroah.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=mlj28@cam.ac.uk \
--cc=rmk@arm.linux.org.uk \
--cc=rob@landley.net \
--cc=rod@whitby.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.