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

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Wed, 18 Jul 2007 13:39:53 -0400,
Rob Landley <rob@landley.net> wrote:

> Nope.  If you recurse down under /sys/class following symlinks, you go into an 
> endless loop bouncing off of /sys/devices and getting pointed back.  If you 
> don't follow symlinks, it works fine up until about 2.6.20 at which point 
> things that were previously directories BECAME symlinks because the 
> directories got moved, and it all broke.

I have no idea what you're doing.

> Which is why I want it documented where to look for these suckers.  Just give 
> me ONE STABLE WAY TO FIND THIS INFORMATION, PLEASE.

See Documentation/sysfs-rules.txt.

> This document is trying to document just enough information to make hotplug 
> work using sysfs (which includes firmware loading if necessary).
> 
> > (And how about referring to Documentation/sysfs-rules.txt?)
> 
> Because there isn't one in 2.6.22, and I've been writing this file on and off 
> for a month as I tracked down various bits of information?

That was a _suggestion_.

> I know.  I'm just trying to show people how to do it.  Notice that this script 
> doesn't DO anything, it just dumps the variables (and proves 
> that /sys/hotplug got called).  You're worried about the scalability of a 
> debugging script.

If you use bash scripts as examples, people will write bash scripts.

> (Rummage)  Seems to be "add, remove, change, online, offline, move"?
> 
> I can list 'em.  Now I'm vaguely curious what generates online and offline 
> events (MII transciever state transitions on a network card, or does this 
> have to do with power saving modes?)  And I have no idea what the difference 
> between "change" and "move" is....

"change" - something about the device has changed
"move" - the device is in a different position in the tree now

You may want to grep for the usage...

> 
> > >   DEVPATH
> > >     Path under /sys at which this device's sysfs directory can be found.
> > >     If $DEVPATH begins with /block/ the event refers to a block device,
> > >     otherwise it refers to a char device.
> >
> > Huh? That's just the path in sysfs. And there's more than block and
> > char :) Check SUBSYSTEM for what your device actually is.
> 
> If you are doing mknod, you need three pieces of information:
> 1) Major, 2) Minor, 3) Block or Char device.  That's pretty much it.  If 
> you're trying to populate /dev you need that info.
> 
> > >   SUBSYSTEM
> > >     If this is "block", it's a block device.  Anything else is a char
> > > device.
> >
> > No. For devices, SUBSYSTEM may be the class (like 'scsi_device') or the
> > bus (like 'pci').
> 
> Do you make a /dev node for either one?
> 
> I'm trying to, at minimum, document what you pass to mknod.  I consider it 
> important to know.

The problem is that your information is wrong. Imagine someone reading
this document, thinking "cool, I'll create a char node if
SUBSYSTEM!=block" and subsequently getting completely confused about
all those SUBSYSTEM==pci events.

> 
> > >   DRIVER
> > >     If present, a suggested driver (module) for handling this device.  No
> > >     relation to whether or not a driver is currently handling the device.
> >
> > No, this actually is the current driver.
> 
> I've had it suggest drivers for devices that didn't have any loaded, and I had 
> it _not_ specify drivers for devices that were loaded.  (I checked.)

The code disagrees with you. If a driver matches and probing succeeds,
it will be specified, otherwise not. Maybe you were checking the wrong
devices?

> Ah yes.  I replied to that when it was first posted.  It's still "here's a 
> list of things NOT to do" rather then telling you what you CAN do.  I'm 
> trying to document what you can do.
> 
> Useful documentation is not "Doing THIS is forbidden.  Doing THIS is 
> forbidden.  Doing THIS is forbidden.  What are you allowed to do?  Guess!  
> Oh, and anything I didn't explicitly mention could change at any time.  Have 
> fun."

It _does_ specify what you may rely on. Don't rely on anything else.

> Sysfs CAN export a stable API.  It may only be a subset of what it's 
> exporting, but it can still do so.

And that is exactly what sysfs-rules.txt is doing. I don't understand
your problem.

If you think that getting this information from sysfs-rules.txt could
be made easier, do a patch against it.