On Sunday 24 June 2007 07:03:39 Kay Sievers wrote:
> On 6/24/07, Rob Landley <[email protected]> wrote:
> > On Saturday 23 June 2007 08:49:47 Kay Sievers wrote:
> > > On 6/22/07, Rob Landley <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
