Re: Rules on how to use sysfs in userspace programs

[Kay Sievers]

On 6/24/07, Rob Landley <rob@xxxxxxxxxxx> wrote:
> 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.

No. "It is planned to merge all three classification-directories into
one place at /sys/subsystem/", but the they will still be available
for backwards compat, and continue to export silly details like
differentiation between class- and bus-devices in the userspace
export.

> 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.

You enter a well defined directory of symlinks, that directory is
named "block". What's so difficult here?

> 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?

"It is planned to merge ..." Today it exists only as a patch and will
show up when the block-conversion eventually gets merged. It will be
/sys/subsystem/$SUBSYSTEM/, just like /sys/bus looks today but
containing _all_ devices from _all_ subsytems in _one_ place with
_one_ access rule. Again, please look at the udev or HAL code, it's
all pretty easy to understand by reading the code.

> > > > 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

There are only symlinks in /sys/bus, no attributes to "find" here.

> Nope, nothing...

Usb and firewire have device nodes at bus devices.

 $ ls -l /sys/bus/usb/devices/*/dev
 /sys/bus/usb/devices/1-2/dev
 /sys/bus/usb/devices/4-1/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...)

SUBSTEM=="block" are block devices, everything else are char devices.
Class-  or bus-devices can be anything, you need to know the subsystem
to distinguish them.

Unfortunately the "dev" file itself does not contain "c123:123",
"b234:8" that would be the proper solution, but reading the subsytem
works fine too for a long time.

> > 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?

Please ...

> Are you unifying char and block devices so mknod doesn't have to distinguish
> between them anymore?

No.

> > > 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.

Sure, that would be nice. any help documenting it in the right way, is
appreciated.

Thanks,
Kay
-
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/