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 -- 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/
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
--
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/
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
--
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/
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
--
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/
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
--
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/
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 -- 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/
/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
--
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/
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 -- 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/
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 -- 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/
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 -- 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/
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 -- 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/
/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
--
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/
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.0 +1100
> +++ ./block/ioctl.c 2007-12-14 16:15:41.0 +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
--
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/
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.0 +1100
+++ ./block/ioctl.c 2007-12-14 16:15:41.0 +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
--
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/
[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.0 +1100
+++ ./block/ioctl.c 2007-12-14 16:15:41.0 +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.h2007-12-14 17:18:50.0 +1100
+++ ./include/linux/fs.h2007-12-14 16:13:03.0 +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 */
--
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/
[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.0 +1100
+++ ./block/ioctl.c 2007-12-14 16:15:41.0 +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.h2007-12-14 17:18:50.0 +1100
+++ ./include/linux/fs.h2007-12-14 16:13:03.0 +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 */
--
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/
