Re: Rules on how to use sysfs in userspace programs
From: Rob Landley
Date: Sun Jun 24 2007 - 15:24:42 EST
On Sunday 24 June 2007 07:03:39 Kay Sievers wrote:
> On 6/24/07, Rob Landley <rob@xxxxxxxxxxx> wrote:
> > On Saturday 23 June 2007 08:49:47 Kay Sievers wrote:
> > > On 6/22/07, Rob Landley <rob@xxxxxxxxxxx> wrote:
> > > > On Friday 08 June 2007 16:36:37 Greg KH wrote:
> > > > > Over time there have been a number of problems when sysfs has
> > > > > changed in "unexpected" ways. Here's a document that Kay wrote a
> > > > > while ago that I'd like to add to the kernel Documentation
> > > > > directory to help userspace programmers out.
> > > > >
> > > > > Any comments or critique of this is greatly appreciated.
> > > >
> > > > Still catching up from my laptop dying.
> > > >
> > > > I find the explanation of /sys/subsystem almost unintelligible. What
> > > > will the new one actually look like?
> > >
> > > "It is planned to merge all three classification-directories into one
> > > place at /sys/subsystem/, following the current layout of the
> > > bus-directories."
> > >
> > > Means that /sys/subsystem/ will have a devices/ directory, full of
> > > symlinks to the devices, all in a flat list. Subsytem-global attribute
> > > files/directories are not mixed with the devices in the same directory
> > > like in /sys/class, it will also not contain any hierarchy like the
> > > layout of /sys/block.
> > But will it still be possible to distinguish block devices from character
> > devices when teaching mdev to quickly scan for devices to populate /dev
> > in embedded systems using the "new" locations for things?
> Sure, all devices have a "subsystem" link, you have to readlink()
> that, and if it ends in "block, you have a blockdev. But as mentioned
> in an earlier mail, you should stop scanning /sys/devices/ and always
> come from the subsystem directories, so you get "block" for free.
I'm not scanning /sys/devices, I'm scanning /sys/block and /sys/class which
this document implies are deprecated and going away. I'm trying to figure
out what replaced them. Now instead of following a path to naturally get
char devices in one pass and block devices in another, it seems I have to
readlink a symlink and do string manipulation to identify the device type
once I've found the device.
I can do this, I'd just like to confirm it's "the way" now, and by "the way" I
mean Greg won't change his mind and yank it next month.
> > > If /sys/subsystem exists, just look at /sys/subsystem/*/devices/*, you
> > > will find every kernel device here, with exactly the logic to access
> > > it. Every device with a "dev" file, it is a char device, unless
> > > $SUBYSTEM=="block".
> > Oh good. That last sentence contains the heuristic I need.
Ok, hang on, looking back on this I'm confused again.
When you say /sys/subsystem are you referring to a literal path (which my sys
directory currently doesn't have a subdirectory named "subsystem"), or do you
mean /sys/$SUBSYSTEM where today I have /sys/class and /sys/block?
> > > If /sys/subsystem/ doesn't exist, you have to search all through
> > > /sys/bus/, /sys/class/, /sys/block/, every directory with completely
> > No, only /sys/class and /sys/block. Currently, /sys/class contains char
> > devices and /sys/block contains block devices. You don't have to invoke
> > mknod for a bus.
> Sure, you have! There are devices in /sys/bus which export device
> nodes, and the number will just grow.
I have yet to encounter any, could you give me some examples?
find /sys/bus -name dev
Would these device nodes be char devices, or block devices, or... something
else entirely? (The practical distinction between /sys/class and /sys/block
used to be that one contained char devices and the other block devices. I
could work with that. I'm sad to see it going away...)
> That's why the document states: "There is no such thing like class-,
> bus-, physical devices, interfaces, and such that you can rely on in
> userspace. Everything is just simply a "device". Class-, bus-,
> physical, ... types are just kernel implementation details, which
> should not be expected by applications that handle devices."
Whether you feed "b" or "c" to mknod is a kernel implementation detail?
Are you unifying char and block devices so mknod doesn't have to distinguish
between them anymore?
> > I'm very interested in helping out with it, and updating mdev based on
> > the documentation rather than the source code, but not until after OLS I
> > expect. :)
> Sure, any help is welcome here.
What I've had to do each time was install a new kernel, find out what had
changed by examination, and update programs to work with the new stuff.
I'd like to be able to do it from documentation.
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/