2007-12-14 06:29:58

by NeilBrown

[permalink] [raw]
Subject: [PATCH 007 of 7] md: Get name for block device in sysfs


Given an fd on a block device, returns a string like

/block/sda/sda1

which can be used to find related information in /sys.

Ideally we should have an ioctl that works on char devices as well,
but that seems far from trivial, so it seems reasonable to have
this until the later can be implemented.

Cc: Jens Axboe <[email protected]>
Signed-off-by: Neil Brown <[email protected]>

### Diffstat output
./block/ioctl.c | 13 +++++++++++++
./include/linux/fs.h | 2 ++
2 files changed, 15 insertions(+)

diff .prev/block/ioctl.c ./block/ioctl.c
--- .prev/block/ioctl.c 2007-12-14 17:18:50.000000000 +1100
+++ ./block/ioctl.c 2007-12-14 16:15:41.000000000 +1100
@@ -227,8 +227,21 @@ int blkdev_ioctl(struct inode *inode, st
struct block_device *bdev = inode->i_bdev;
struct gendisk *disk = bdev->bd_disk;
int ret, n;
+ char b[BDEVNAME_SIZE*2 + 10];

switch(cmd) {
+ case BLKGETNAME:
+ strcpy(b, "/block/");
+ bdevname(bdev->bd_contains, b+7);
+ if (bdev->bd_contains != bdev) {
+ char *e = b + strlen(b);
+ *e++ = '/';
+ bdevname(bdev, e);
+ }
+ if (copy_to_user((char __user *)arg, b, strlen(b)+1))
+ return -EFAULT;
+ return 0;
+
case BLKFLSBUF:
if (!capable(CAP_SYS_ADMIN))
return -EACCES;

diff .prev/include/linux/fs.h ./include/linux/fs.h
--- .prev/include/linux/fs.h 2007-12-14 17:18:50.000000000 +1100
+++ ./include/linux/fs.h 2007-12-14 16:13:03.000000000 +1100
@@ -218,6 +218,8 @@ extern int dir_notify_enable;
#define BLKTRACESTOP _IO(0x12,117)
#define BLKTRACETEARDOWN _IO(0x12,118)

+#define BLKGETNAME _IOR(0x12, 119, char [1024])
+
#define BMAP_IOCTL 1 /* obsolete - kept for compatibility */
#define FIBMAP _IO(0x00,1) /* bmap access */
#define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */


2007-12-15 16:58:41

by Kay Sievers

[permalink] [raw]
Subject: Re: [PATCH 007 of 7] md: Get name for block device in sysfs

On Dec 14, 2007 7:26 AM, NeilBrown <[email protected]> wrote:
>
> Given an fd on a block device, returns a string like
>
> /block/sda/sda1
>
> which can be used to find related information in /sys.
>
> Ideally we should have an ioctl that works on char devices as well,
> but that seems far from trivial, so it seems reasonable to have
> this until the later can be implemented.
>
> Cc: Jens Axboe <[email protected]>
> Signed-off-by: Neil Brown <[email protected]>
>
> ### Diffstat output
> ./block/ioctl.c | 13 +++++++++++++
> ./include/linux/fs.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff .prev/block/ioctl.c ./block/ioctl.c
> --- .prev/block/ioctl.c 2007-12-14 17:18:50.000000000 +1100
> +++ ./block/ioctl.c 2007-12-14 16:15:41.000000000 +1100
> @@ -227,8 +227,21 @@ int blkdev_ioctl(struct inode *inode, st
> struct block_device *bdev = inode->i_bdev;
> struct gendisk *disk = bdev->bd_disk;
> int ret, n;
> + char b[BDEVNAME_SIZE*2 + 10];
>
> switch(cmd) {
> + case BLKGETNAME:
> + strcpy(b, "/block/");

As pointed out to when you came up with the idea, we can't do this. A devpath
is a path to the device and will not necessarily start with "/block" for block
devices. It may start with "/devices" and can be much longer than
BDEVNAME_SIZE*2 + 10.

Please do not apply!

Kay

2007-12-16 22:43:41

by NeilBrown

[permalink] [raw]
Subject: Re: [PATCH 007 of 7] md: Get name for block device in sysfs

On Saturday December 15, [email protected] wrote:
> On Dec 14, 2007 7:26 AM, NeilBrown <[email protected]> wrote:
> >
> > Given an fd on a block device, returns a string like
> >
> > /block/sda/sda1
> >
> > which can be used to find related information in /sys.
....
>
> As pointed out to when you came up with the idea, we can't do this. A devpath
> is a path to the device and will not necessarily start with "/block" for block
> devices. It may start with "/devices" and can be much longer than
> BDEVNAME_SIZE*2 + 10.


When you say "will not necessarily" can I take that to mean that it
currently does, but it might (will) change??
In that case can we have the patch as it stands and when the path to
block devices in /sys changes, the ioctl can be changed at the same
time to match?

Or are you saying that as the kernel is today, some block devices
appear under /devices/..., in which case could you please give an
example?

Thanks,
NeilBrown

2007-12-17 02:11:43

by Kay Sievers

[permalink] [raw]
Subject: Re: [PATCH 007 of 7] md: Get name for block device in sysfs

On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
> On Saturday December 15, [email protected] wrote:
> > On Dec 14, 2007 7:26 AM, NeilBrown <[email protected]> wrote:
> > >
> > > Given an fd on a block device, returns a string like
> > >
> > > /block/sda/sda1
> > >
> > > which can be used to find related information in /sys.
> ....
> >
> > As pointed out to when you came up with the idea, we can't do this. A devpath
> > is a path to the device and will not necessarily start with "/block" for block
> > devices. It may start with "/devices" and can be much longer than
> > BDEVNAME_SIZE*2 + 10.
>
> When you say "will not necessarily" can I take that to mean that it
> currently does, but it might (will) change??

It's in -mm. The devpath for all block devices, like for all other
devices, will start with /devices/* if !SYSFS_DEPRECATED.

> In that case can we have the patch as it stands and when the path to
> block devices in /sys changes, the ioctl can be changed at the same
> time to match?

No, you have to use kobject_get_path() to get the path to the object.
This will also handle devices where the name contains '/' which needs to
be translated to '!', which is broken in this patch.

> Or are you saying that as the kernel is today, some block devices
> appear under /devices/..., in which case could you please give an
> example?

We expect the next kernel to have it.

Btw: BLKGETNAME should probably be renamed to something which contains
DEVPATH, to make clear that it's a path to, and not the name of the
device.

Kay

2007-12-17 05:29:29

by Michael Tokarev

[permalink] [raw]
Subject: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

Kay Sievers wrote:
> On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
>> On Saturday December 15, [email protected] wrote:
>>> On Dec 14, 2007 7:26 AM, NeilBrown <[email protected]> wrote:
>>>> Given an fd on a block device, returns a string like
>>>>
>>>> /block/sda/sda1
>>>>
>>>> which can be used to find related information in /sys.
>> ....
>>> As pointed out to when you came up with the idea, we can't do this. A devpath
>>> is a path to the device and will not necessarily start with "/block" for block
>>> devices. It may start with "/devices" and can be much longer than
>>> BDEVNAME_SIZE*2 + 10.
>> When you say "will not necessarily" can I take that to mean that it
>> currently does, but it might (will) change??
>
> It's in -mm. The devpath for all block devices, like for all other
> devices, will start with /devices/* if !SYSFS_DEPRECATED.

This is the second time I come across this (planned?) change, and for
the second time I can't understand it.

How to distinguish char devices from block devices in sysfs?
Is the only way to read a symlink `subsystem' in the device
directory?

For now, I've a shell code (used heavily in numerous places),
which looks like this:

function makedev() {
...
case $DEVPATH in
/block/*) TYPE=b ;;
*) TYPE=c ;;
esac
...
mknod /dev/$DEV $TYPE $MAJOR $MINOR
}

The only external process invocation in there is mknod, all
the rest is done using pure shell constructs. Is it really
necessary to spawn another process just to read a symlink
now? It will be almost 2 times slower....

(Sure thing this may be rewritten in C, but using shell it's
MUCH easier to customize if necessary.)

Also, /sys/block/ directory is very easy to use currently, --
unlike other /sys/ stuff which is way too deep and often
placed in unknown/unexpected places (and /sys/class/ and
/sys/bus/ directories are changing all the time).

What's the benefit of moving things from /sys/block/ to
/sys/devices/ ?

Thanks.

/mjt

2007-12-17 08:25:41

by Kay Sievers

[permalink] [raw]
Subject: Re: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

On Mon, 2007-12-17 at 08:29 +0300, Michael Tokarev wrote:
> Kay Sievers wrote:
> > On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
> >> On Saturday December 15, [email protected] wrote:
> >>> On Dec 14, 2007 7:26 AM, NeilBrown <[email protected]> wrote:
> >>>> Given an fd on a block device, returns a string like
> >>>>
> >>>> /block/sda/sda1
> >>>>
> >>>> which can be used to find related information in /sys.
> >> ....
> >>> As pointed out to when you came up with the idea, we can't do this. A devpath
> >>> is a path to the device and will not necessarily start with "/block" for block
> >>> devices. It may start with "/devices" and can be much longer than
> >>> BDEVNAME_SIZE*2 + 10.
> >> When you say "will not necessarily" can I take that to mean that it
> >> currently does, but it might (will) change??
> >
> > It's in -mm. The devpath for all block devices, like for all other
> > devices, will start with /devices/* if !SYSFS_DEPRECATED.
>
> This is the second time I come across this (planned?) change, and for
> the second time I can't understand it.
>
> How to distinguish char devices from block devices in sysfs?
> Is the only way to read a symlink `subsystem' in the device
> directory?

By its subsystem value (block), from the symlink, from the environment,
or from $1.

> For now, I've a shell code (used heavily in numerous places),
> which looks like this:
>
> function makedev() {
> ...
> case $DEVPATH in
> /block/*) TYPE=b ;;
> *) TYPE=c ;;
> esac
> ...
> mknod /dev/$DEV $TYPE $MAJOR $MINOR
> }
>
> The only external process invocation in there is mknod, all
> the rest is done using pure shell constructs. Is it really
> necessary to spawn another process just to read a symlink
> now? It will be almost 2 times slower....

No need.

> (Sure thing this may be rewritten in C, but using shell it's
> MUCH easier to customize if necessary.)

$SUBSYSTEM == "block"

> Also, /sys/block/ directory is very easy to use currently, --
> unlike other /sys/ stuff which is way too deep and often
> placed in unknown/unexpected places (and /sys/class/ and
> /sys/bus/ directories are changing all the time).

/sys/block is still there and contains symlinks. And all this happens
only for !SYSFS_DEPRECATED.

> What's the benefit of moving things from /sys/block/ to
> /sys/devices/ ?

Unification. Block devices are "struct devices", use a class, use the
common driver core code instead of their own, show up in the tree, and
can be parents for other devices.

Kay

2007-12-17 08:33:03

by Michael Tokarev

[permalink] [raw]
Subject: Re: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

Kay Sievers wrote:
> On Mon, 2007-12-17 at 08:29 +0300, Michael Tokarev wrote:
[]
>> How to distinguish char devices from block devices in sysfs?
>> Is the only way to read a symlink `subsystem' in the device
>> directory?
>
> By its subsystem value (block), from the symlink, from the environment,
> or from $1.

Environment and $1 comes as arguments for hotplug helper, not
when scanning /sys/.

>> For now, I've a shell code (used heavily in numerous places),
>> which looks like this:
>>
>> function makedev() {
>> ...
>> case $DEVPATH in
>> /block/*) TYPE=b ;;
>> *) TYPE=c ;;
>> esac
>> ...
>> mknod /dev/$DEV $TYPE $MAJOR $MINOR
>> }
>>
>> The only external process invocation in there is mknod, all
>> the rest is done using pure shell constructs. Is it really
>> necessary to spawn another process just to read a symlink
>> now? It will be almost 2 times slower....
>
> No need.

It seems there IS a need now ;)

Thanks for the clarification.

/mjt

2007-12-17 09:13:19

by Michael Tokarev

[permalink] [raw]
Subject: Re: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

Michael Tokarev wrote:
> Kay Sievers wrote:
>> On Mon, 2007-12-17 at 08:29 +0300, Michael Tokarev wrote:
> []
>>> How to distinguish char devices from block devices in sysfs?
>>> Is the only way to read a symlink `subsystem' in the device
>>> directory?
>> By its subsystem value (block), from the symlink, from the environment,
>> or from $1.
>
> Environment and $1 comes as arguments for hotplug helper, not
> when scanning /sys/.

By the way, that's one of reasons I asked about useful content
in uevent files (but failed to provide a patch so far ;).
In 2.6.23, those files ARE readable finally, but doesn't
contain much info yet.

/mjt