[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1180015628.3579.41.camel@lov.localdomain>
Date: Thu, 24 May 2007 16:07:08 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Michael Tokarev <mjt@....msk.ru>
Cc: Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 &
4 testers wanted)
On Thu, 2007-05-24 at 00:35 +0400, Michael Tokarev wrote:
> Greg KH wrote:
> []
> > From: Kay Sievers <kay.sievers@...y.org>
> > Subject: Driver core: convert block from raw kobjects to core devices
> >
> > This moves the block devices to /sys/class/block. It will create a
> > flat list of all block devices, with the disks and partitions in one
> > directory. For compatibility /sys/block is created and contains symlinks
> > to the disks.
>
> What's the proper way now to figure out which device type it is --
> block or char?
>>From the "subsystem" value of the device, only if it's "block" it's a
block node, everything else is a char node.
> Before, I had a function (in my udev-alike userspace app), something akin
> sysfs_scan_devices(char *topdir, mode_t type), and called it twice --
>
> sysfs_scan_devices("/block", S_IFBLK);
> sysfs_scan_devices("/devices", S_IFCHR);
>
> How it's supposed to work now?
You need to resolve the symlink, back to the originating subsystem the
device belongs to.
Just better read the flat directories /sys/bus/*/devices/*, /sys/class/*/*,
and you get the subsystem values for free, instead of searching through
the directory tree in /sys/devices/.
> (Note that it skips symlinks for obvious
> reason, hence it can't find anything in /sys/block, even with the compat
> "layer" in place)
Everything can be a symlink or a directory, you can't assume one or the
other. You better start from the buses and classes. The udevtrigger code
or the HAL coldplug code work with all versions of sysfs, just look at
these as an example.
Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists