Re: Rules on how to use sysfs in userspace programs

[Rob Landley <rob@landley.net>]

On Sunday 24 June 2007 07:03:39 Kay Sievers wrote:
> On 6/24/07, Rob Landley <rob@landley.net> wrote:
> > On Saturday 23 June 2007 08:49:47 Kay Sievers wrote:
> > > On 6/22/07, Rob Landley <rob@landley.net> 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

Nope, nothing...

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.

> Thanks,
> Kay

Rob
-- 
"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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/