[lkml]   [2007]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Documentation for sysfs, hotplug, and firmware loading.
    On Wed, 18 Jul 2007 13:39:53 -0400,
    Rob Landley <> 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

    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

    > 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.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-19 10:25    [W:0.027 / U:70.736 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site