On Wed, 18 Jul 2007 13:39:53 -0400, Rob Landley <[EMAIL PROTECTED]> 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. - 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/
