* [PATCH 1/3] Add virtioblk_id tool to extract drive serial numbers
From: Ryan Harper @ 2010-06-10 19:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-2-git-send-email-ryanh@us.ibm.com>
Use the 'VBID' virtio-blk ioctl to extract drive serial numbers
to be used for building disk/by-id symlinks. After extracting
the serial number of the device it prints out the minimum info
needed in a similar format to `scsi_id --export` so that the
persistent-storage rules can process the serial information.
This program depends on the virtio-blk serial device patches posted
here[1] being applied to qemu and linux-kernel.
Here is what the output looks like:
% ./virtioblk_id /dev/vdb
ID_VIRTIO=1
ID_TYPE=disk
ID_SERIAL=QM00001
ID_SERIAL_SHORT=QM00001
1. http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01869.html
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
Makefile.am | 7 +++
| 83 ++++++++++++++++++++++++++++++++++++
2 files changed, 90 insertions(+), 0 deletions(-)
create mode 100644 extras/virtioblk_id/virtioblk_id.c
diff --git a/Makefile.am b/Makefile.am
index bafe4c7..6b8f41b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -251,6 +251,13 @@ extras_path_id_path_id_LDADD = libudev/libudev-private.la
libexec_PROGRAMS += extras/path_id/path_id
# ------------------------------------------------------------------------------
+# virtioblk_id - virtioblk inquery to extract disk serial numbers
+# ------------------------------------------------------------------------------
+extras_virtioblk_id_virtioblk_id_SOURCES = extras/virtioblk_id/virtioblk_id.c
+extras_virtioblk_id_virtioblk_id_LDADD = libudev/libudev-private.la
+libexec_PROGRAMS += extras/virtioblk_id/virtioblk_id
+
+# ------------------------------------------------------------------------------
# fstab_import - import /etc/fstab entry for block device
# ------------------------------------------------------------------------------
extras_fstab_import_fstab_import_SOURCES = extras/fstab_import/fstab_import.c
--git a/extras/virtioblk_id/virtioblk_id.c b/extras/virtioblk_id/virtioblk_id.c
new file mode 100644
index 0000000..be9ff2e
--- /dev/null
+++ b/extras/virtioblk_id/virtioblk_id.c
@@ -0,0 +1,83 @@
+/*
+ * extract disk serial from virtio-blk devices
+ * and print enough values to allow udev to create disk/by-id/ symlinks
+ *
+ * Copyright IBM, Corp. 2010
+ *
+ * Authors:
+ * John Cooper <john.cooper@redhat.com>
+ * Ryan Harper <ryanh@us.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ */
+
+#include <stdio.h>
+#include <strings.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <linux/hdreg.h>
+#include <getopt.h>
+
+/* virtio-blk VBID ioctl */
+#define IOCTL_CMD 0x56424944
+
+int main(int argc, char **argv)
+{
+ int fd, rv;
+ const char *device;
+ char buf[255];
+
+ int opt_debug = 0;
+ static const char *option_string = "d";
+ static struct option options[] = {
+ {"debug", 0, NULL, 'd'},
+ {"help", 0, NULL, 'h'},
+ {0, 0, NULL, 0}
+ };
+
+ while (1) {
+ int option;
+ option = getopt_long(argc, argv, "dh", options, NULL);
+ if (option = -1)
+ break;
+ switch (option) {
+ case 'd':
+ opt_debug = 1;
+ break;
+ case 'h':
+ printf("Usage: virtioblk_id [--debug] [--help] <device>\n"
+ " --debug print debugging information\n"
+ " --help print this help text\n\n");
+ default:
+ rv = 1;
+ goto exit;
+ }
+ }
+
+ device = argv[optind];
+ if (device = NULL) {
+ fprintf(stderr, "no device specified\n");
+ rv = 1;
+ goto exit;
+ }
+
+
+ bzero(buf, sizeof (buf));
+ if ((fd = open(device, O_RDONLY)) < 0) {
+ if (opt_debug = 1)
+ perror("open");
+ } else if ((rv = ioctl(fd, IOCTL_CMD, buf)) < 0) {
+ if (opt_debug = 1)
+ perror("ioctl");
+ } else {
+ printf("ID_VIRTIO=1\n");
+ printf("ID_TYPE=disk\n");
+ printf("ID_SERIAL=%s\n", buf);
+ printf("ID_SERIAL_SHORT=%s\n", buf);
+ rv = 0;
+ }
+
+ exit:
+ return rv;
+}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] Add virtio-blk support to path_id
From: Ryan Harper @ 2010-06-10 19:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-3-git-send-email-ryanh@us.ibm.com>
This patch adds a case handling path_id invoked on a virtio-blk device.
Currently path_id walks the parent path to virtio-pci but doesn't know
that it's the end of the path and exits without building the path (providing no
output resulting in no disk/by-path symlinks to virtio-blk devices).
This patch handles the virtio-pci path and updates the path accordingly.
/lib/udev/path_id --debug /block/vda
udev_device_new_from_syspath: device 0x2300120 has devpath '/devices/virtio-pci/virtio1/block/vda'
udev_device_new_from_syspath: device 0x2300380 has devpath '/devices/virtio-pci/virtio1'
udev_device_new_from_syspath: device 0x2300670 has devpath '/devices/virtio-pci'
ID_PATH=virtio-pci-virtio1
And with the current persistent-storage rules generates:
% ls -al /dev/disk/by-path | grep vda
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-pci-virtio1 -> ../../vda
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
| 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
index dcee378..c19bfd0 100644
--- a/extras/path_id/path_id.c
+++ b/extras/path_id/path_id.c
@@ -448,6 +448,9 @@ int main(int argc, char **argv)
} else if (strcmp(subsys, "xen") = 0) {
path_prepend(&path, "xen-%s", udev_device_get_sysname(parent));
parent = skip_subsystem(parent, "xen");
+ } else if (strcmp(subsys, "virtio") = 0) {
+ path_prepend(&path, "virtio-pci-%s", udev_device_get_sysname(parent));
+ parent = skip_subsystem(parent, "virtio");
}
parent = udev_device_get_parent(parent);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] Add virtio-blk support to persistent-storage rules
From: Ryan Harper @ 2010-06-10 19:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-4-git-send-email-ryanh@us.ibm.com>
Using virtioblk_id add rules to extract drive serial numbers and generate
by-id links for the block device and partitions.
With these rules added, we now see the following symlinks in disk/by-id
% ls -al /dev/disk/by-id | grep vdb
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-QM00001 -> ../../vda
lrwxrwxrwx. 1 root root 10 Jun 1 22:09 virtio-QM00001-part1 -> ../../vda1
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
rules/rules.d/60-persistent-storage.rules | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/rules/rules.d/60-persistent-storage.rules b/rules/rules.d/60-persistent-storage.rules
index 1f46041..da73526 100644
--- a/rules/rules.d/60-persistent-storage.rules
+++ b/rules/rules.d/60-persistent-storage.rules
@@ -30,6 +30,11 @@ KERNEL="cciss*", ENV{DEVTYPE}="disk", ENV{ID_SERIAL}!="?*", IMPORT{program}="s
KERNEL="sd*|sr*|cciss*", ENV{DEVTYPE}="disk", ENV{ID_SERIAL}="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
KERNEL="sd*|cciss*", ENV{DEVTYPE}="partition", ENV{ID_SERIAL}="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
+# virtioblk
+KERNEL="vd*[!0-9]", IMPORT{program}="virtioblk_id $tempnode"
+KERNEL="vd*[!0-9]", ENV{ID_SERIAL}="?*", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
+KERNEL="vd*[0-9]", ENV{ID_SERIAL}="?*", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
+
# firewire
KERNEL="sd*[!0-9]|sr*", ATTRS{ieee1394_id}="?*", SYMLINK+="disk/by-id/ieee1394-$attr{ieee1394_id}"
KERNEL="sd*[0-9]", ATTRS{ieee1394_id}="?*", SYMLINK+="disk/by-id/ieee1394-$attr{ieee1394_id}-part%n"
--
1.6.3.3
^ permalink raw reply related
* blacklist of hard drives that misreport serial numbers
From: Ethan Baldridge @ 2010-06-11 2:58 UTC (permalink / raw)
To: linux-hotplug
Does such a list exist?
I've got a system that depends on the symlink in /dev/disk/by-id to
identify which of the external drives at our datacenter contains the
data that needs to be removed and shipped out after we export to the
drive.
This worked fabulously during in-house testing, but now that the system
is in production we find that some Toshiba drives (at least) don't
report a serial number to the OS that looks anything like what is
printed on the outside of the drive itself. That complicates things.
Is this dastardly behavior limited to Toshiba, or merely the specific
model in question, or is it a known widespread problem for drives from
any vendor (and is it at least guaranteed that certain models are safe)?
Thanks,
Ethan Baldridge
^ permalink raw reply
* Re: blacklist of hard drives that misreport serial numbers
From: David Zeuthen @ 2010-06-11 3:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276225119.2765.38.camel@obsidian>
Hi,
On Thu, Jun 10, 2010 at 10:58 PM, Ethan Baldridge
<baldridge.ethan@gmail.com> wrote:
> Does such a list exist?
>
> I've got a system that depends on the symlink in /dev/disk/by-id to
> identify which of the external drives at our datacenter contains the
> data that needs to be removed and shipped out after we export to the
> drive.
>
> This worked fabulously during in-house testing, but now that the system
> is in production we find that some Toshiba drives (at least) don't
> report a serial number to the OS that looks anything like what is
> printed on the outside of the drive itself. That complicates things.
>
> Is this dastardly behavior limited to Toshiba, or merely the specific
> model in question, or is it a known widespread problem for drives from
> any vendor (and is it at least guaranteed that certain models are safe)?
For SCSI disks (e.g. data obtained via scsi_id), ID_SERIAL isn't
really the page 0x80 serial number that is typically printed on the
label of the hard disk. This commit has some more information
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hN9fdfccbdd16f0cfdb5c8fa8484a8ba0f2e69d3
and exports the serial number and WWN in ID_WWN and ID_SCSI_SERIAL.
FWIW, I don't think we use ID_SCSI_SERIAL in any /dev/disk symlinks
but we probably could. Any chance you could try seeing if
ID_SCSI_SERIAL works for you? It's available since udev version 148 or
later.
Also, we do use ID_WWN for /dev/disk/by-id/wwn-0x* symlinks (and this
is set for both SCSI (including e.g. SAS) through scsi_id and ATA
through ata_id) - maybe you can use the by-id/wwn-* symlinks instead?
David
^ permalink raw reply
* Re: blacklist of hard drives that misreport serial numbers
From: Ethan Baldridge @ 2010-06-11 3:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276225119.2765.38.camel@obsidian>
On Thu, 2010-06-10 at 23:36 -0400, David Zeuthen wrote:
> Hi,
>
> On Thu, Jun 10, 2010 at 10:58 PM, Ethan Baldridge
> <baldridge.ethan@gmail.com> wrote:
> > Does such a list exist?
> >
> > I've got a system that depends on the symlink in /dev/disk/by-id to
> > identify which of the external drives at our datacenter contains the
> > data that needs to be removed and shipped out after we export to the
> > drive.
> >
> > This worked fabulously during in-house testing, but now that the system
> > is in production we find that some Toshiba drives (at least) don't
> > report a serial number to the OS that looks anything like what is
> > printed on the outside of the drive itself. That complicates things.
> >
> > Is this dastardly behavior limited to Toshiba, or merely the specific
> > model in question, or is it a known widespread problem for drives from
> > any vendor (and is it at least guaranteed that certain models are safe)?
>
> For SCSI disks (e.g. data obtained via scsi_id), ID_SERIAL isn't
> really the page 0x80 serial number that is typically printed on the
> label of the hard disk. This commit has some more information
>
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hN9fdfccbdd16f0cfdb5c8fa8484a8ba0f2e69d3
>
> and exports the serial number and WWN in ID_WWN and ID_SCSI_SERIAL.
>
> FWIW, I don't think we use ID_SCSI_SERIAL in any /dev/disk symlinks
> but we probably could. Any chance you could try seeing if
> ID_SCSI_SERIAL works for you? It's available since udev version 148 or
> later.
>
> Also, we do use ID_WWN for /dev/disk/by-id/wwn-0x* symlinks (and this
> is set for both SCSI (including e.g. SAS) through scsi_id and ATA
> through ata_id) - maybe you can use the by-id/wwn-* symlinks instead?
>
> David
Thanks for the info, David, but unfortunately these are USB drives, and
scsi_id doesn't seem to return anything (although this is with udev
version 147, so I can try upgrading, but that patch only seems to affect
the scsi subsystem - has something similar been done to usb?)
$ /lib/udev/usb_id -x /block/sdg
ID_VENDOR=Toshiba
ID_VENDOR_ENC=Toshiba\x20
ID_VENDOR_ID\x0480
ID_MODEL=External_USB_HDD
ID_MODEL_ENC=External\x20USB\x20HDD
ID_MODEL_ID 03
ID_REVISION\x010f
ID_SERIAL=Toshiba_External_USB_HDD_2010040104E4-0:0
ID_SERIAL_SHORT 10040104E4
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM\0
ID_USB_DRIVER=usb-storage
$ /lib/udev/scsi_id -x /block/sdg
$
Versus this result for a Seagate drive:
$ /lib/udev/usb_id -x /block/sdf
ID_VENDOR=Seagate
ID_VENDOR_ENC=Seagate\x20
ID_VENDOR_ID\vc2
ID_MODEL=FreeAgentDesktop
ID_MODEL_ENC=FreeAgentDesktop
ID_MODEL_ID000
ID_REVISION\x100F
ID_SERIAL=Seagate_FreeAgentDesktop_5QM0A7X7-0:0
ID_SERIAL_SHORT=5QM0A7X7
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM\0
ID_USB_DRIVER=usb-storage
And this number actually does match what one would expect by looking at
the bottom of the drive enclosure.
The serial is used in the symlinks in by-id here:
lrwxrwxrwx 1 root root 9 2010-05-13 14:32
usb-Seagate_FreeAgentDesktop_5QM0A7X7-0:0 -> ../../sdf
lrwxrwxrwx 1 root root 10 2010-05-13 14:32
usb-Seagate_FreeAgentDesktop_5QM0A7X7-0:0-part1 -> ../../sdf1
lrwxrwxrwx 1 root root 9 2010-05-20 17:25
usb-Toshiba_External_USB_HDD_2010040104E4-0:0 -> ../../sdg
lrwxrwxrwx 1 root root 10 2010-05-20 17:25
usb-Toshiba_External_USB_HDD_2010040104E4-0:0-part1 -> ../../sdg1
lrwxrwxrwx 1 root root 9 2010-06-09 10:37
usb-Toshiba_External_USB_HDD_2010040105DD-0:0 -> ../../sde
lrwxrwxrwx 1 root root 10 2010-06-09 10:37
usb-Toshiba_External_USB_HDD_2010040105DD-0:0-part1 -> ../../sde1
Thanks,
Ethan
^ permalink raw reply
* udev and C3 processor
From: nunes @ 2010-06-11 13:52 UTC (permalink / raw)
To: linux-hotplug
Helo,
since two years ago, something happened to udev that
make my Laptop to hang: it is an old Elitegroup with C3 VIA
processor. Linux boots now only if I give "nohotplug" as
an option to the kernel. Otherwise it hangs immediately after
the udev message. The old udev (more than 2 years old) and
kernel was ok.
What can be the problem?
thanks in advance
Genaldo
^ permalink raw reply
* Re: udev and C3 processor
From: Greg KH @ 2010-06-11 14:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LNX.2.00.1006111009120.20427@wwww.mtm.ufsc.br>
On Fri, Jun 11, 2010 at 10:17:03AM -0400, nunes@mtm.ufsc.br wrote:
>
> Helo,
> since two years ago, something happened to udev that
> make my Laptop to hang: it is an old Elitegroup with C3 VIA
> processor. Linux boots now only if I give "nohotplug" as
> an option to the kernel. Otherwise it hangs immediately after
> the udev message. The old udev (more than 2 years old) and
> kernel was ok.
> What can be the problem?
Your kernel is loading a module that causes your machine to crash. It's
not a udev issue.
good luck,
greg k-h
^ permalink raw reply
* Re: blacklist of hard drives that misreport serial numbers
From: David Zeuthen @ 2010-06-11 22:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276225119.2765.38.camel@obsidian>
Hey,
On Thu, Jun 10, 2010 at 11:57 PM, Ethan Baldridge
<baldridge.ethan@gmail.com> wrote:
> Thanks for the info, David, but unfortunately these are USB drives, and
> scsi_id doesn't seem to return anything (although this is with udev
> version 147, so I can try upgrading, but that patch only seems to affect
> the scsi subsystem - has something similar been done to usb?)
I think that we always use the USB serial number for any device
connected via USB. I remember something about that if the USB device
is a ATA disk and the bridge is sufficiently compatible, it should be
possible to retrieve the ATA serial number from IDENTIFY data.
Presumably it's a simple matter of attempting to run ata_id (which I
don't think we currently do).
Try checking the devices with ata_id (from udev), hdparm(8) and
skdump(1) and check if the serial reported by them is what you're
after?
(I'm mentioning skdump(1) because it has some extra secret sauce for
dealing with ATA devices behind certain kinds of USB bridges.)
> And this number actually does match what one would expect by looking at
> the bottom of the drive enclosure.
This is probably just a coincidence. In general I don't think you can
make any assumptions about what kind of serial number vendors put on
the *enclosure*. If it was ATA or SAS disks you could probably expect
the vendors to put the serial number or WWN on the hard disks itself.
That said, in the case where we can extract both the ATA serial number
and the USB serial number for a disk, I think we should prefer the ATA
one. Or maybe, for symlinks at least, we should use both. Kay, what do
you think?
David
^ permalink raw reply
* Re: blacklist of hard drives that misreport serial numbers
From: Ethan Baldridge @ 2010-06-12 3:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276225119.2765.38.camel@obsidian>
Thanks, David,
On Fri, 2010-06-11 at 18:38 -0400, David Zeuthen wrote:
> Hey,
>
> On Thu, Jun 10, 2010 at 11:57 PM, Ethan Baldridge
> <baldridge.ethan@gmail.com> wrote:
> > Thanks for the info, David, but unfortunately these are USB drives, and
> > scsi_id doesn't seem to return anything (although this is with udev
> > version 147, so I can try upgrading, but that patch only seems to affect
> > the scsi subsystem - has something similar been done to usb?)
>
> I think that we always use the USB serial number for any device
> connected via USB. I remember something about that if the USB device
> is a ATA disk and the bridge is sufficiently compatible, it should be
> possible to retrieve the ATA serial number from IDENTIFY data.
> Presumably it's a simple matter of attempting to run ata_id (which I
> don't think we currently do).
>
> Try checking the devices with ata_id (from udev), hdparm(8) and
> skdump(1) and check if the serial reported by them is what you're
> after?
>
ata_id returns nothing for any of the USB drives.
hdparm also gives nothing for any of them except:
HDIO_DRIVE_CMD(identify) failed: Invalid exchange
HDIO_GET_IDENTITY failed: Invalid argument
skdump gave much more interesting results.
For the Seagate drive (which is already returning the "proper" - or at
least expected - serial number) it gave a whole battery of SMART data,
as well as Model: [ST3500820AS], and Serial: [5QM0A7X7]
For the Toshiba drives (which do not have the expected serial number) I
only got:
$ sudo skdump /dev/sdg
Device: sat12:/dev/sdg
Type: 12 Byte SCSI ATA SAT Passthru
Size: 305245 MiB
Awake: Operation not supported
ATA SMART not supported.
So it seems like that's also a dead-end. I think these drives just don't
give useful information to the operating system. Of course, you can
disagree and say that in reality they don't have useful information
printed on them, but either way it comes down to the same thing as far
as I can see - "don't buy these if you care what the serial number is."
The drives are the pocket-size ones in a solid molded enclosure with no
way to get at the actual drive, so it's definitely not helpful to know
that *if* I could take it apart and look at the drive, it *might* have
the number I want printed on it. Toshiba should really put that on the
outside (as Seagate apparently does, at least for one model.)
Thanks,
Ethan
^ permalink raw reply
* New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-12 12:54 UTC (permalink / raw)
To: linux-hotplug
Hi,
I have written a driver for xD card reader and xD/SmartMedia FTL that is
usually mandatory to use with xD cards.
I think this can be added to 80-drivers.rule
SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
And this for devicekit, not sure where to add:
KERNEL="smblk*", ENV{ID_DRIVE_FLASH}="1"
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH 1/3] Add virtioblk_id tool to extract drive serial numbers
From: Kay Sievers @ 2010-06-14 8:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-2-git-send-email-ryanh@us.ibm.com>
On Thu, Jun 10, 2010 at 21:16, Ryan Harper <ryanh@us.ibm.com> wrote:
> Use the 'VBID' virtio-blk ioctl to extract drive serial numbers
> to be used for building disk/by-id symlinks. Â After extracting
> the serial number of the device it prints out the minimum info
> needed in a similar format to `scsi_id --export` so that the
> persistent-storage rules can process the serial information.
>
> This program depends on the virtio-blk serial device patches posted
> here[1] being applied to qemu and linux-kernel.
>
> Here is what the output looks like:
>
> % ./virtioblk_id /dev/vdb
> ID_VIRTIO=1
> ID_TYPE=disk
> ID_SERIAL=QM00001
> ID_SERIAL_SHORT=QM00001
As requested in the ealier mail. Please provide a good reason why the
kernel code can not create a "serial" file (or whatever fits your
needs) in sysfs at the block device.
Other subsystems are doing the same thing like:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/mmc/core/mmc.c;h‰f7a25b7ac12ab17f7baa9a18e0d980fe1c50eb;hb=HEAD#l270
We don't like to accumulate special purpose tools based on rather
weird ioctls for newly developed stuff, which can be replaced with a
few obviously and generally useful lines of code in the kernel driver.
As I think the general direction of solving the problem you describe
is fundamentally wrong, I'll apply this only, if there are valid
reasons not to add this to sysfs.
Thanks,
Kay
^ permalink raw reply
* Re: Questions on udev-acl rules, ACL_MANAGE + bug report
From: Kay Sievers @ 2010-06-14 9:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <87k4q82l9k.fsf@sonic.technologeek.org>
On Wed, Jun 9, 2010 at 19:01, Julien BLACHE <jblache@debian.org> wrote:
> I am wondering how one is supposed to integrate/interact with udev-acl
> outside of its dedicated rules file, as using ACL_MANAGE outside this
> file is strictly forbidden.
>
> Setting dedicated variables via other rules to have them checked and
> acted upon by the dedicated udev-acl rules seems suboptimal in more than
> one way :/
>
> So, what's the long-term plan on this? I've discussed this with Marco
> d'Itri, our udev maintainer, and a couple other Debian developers and we
> all wonder how this is supposed to work on the long term. Can someone
> shed light on this for us, please?
There is no real long-term plan to explain. It's just that stuff is
moving all the time. There might be upcoming changes in ConsoleKit
which require changes again. I'm not really involved in this, don't
know the details, but I know people talking about new stuff.
We need to split classification from policy here, to be able to
plug-in a possible finer-grained policy that's based on more
ConsoleKit properties than "local". That's why the flags in udev flags
to mark devices should not be used directly.
> [SANE upstream hat on]
> Second point in this mail, the rules used for SCSI scanners by udev-acl
> are too broad as they are today; they may match SCSI devices that aren't
> scanners (like tape libraries and other SCSI equipment reporting a
> control interface with a SCSI type of "Processor", for instance - this
> has been seen before).
>
> Instead of duplicating the rules from libsane, I propose to also set
> libsane_matched for SCSI scanners starting with the next SANE release
> (whenever that happens, and I'd encourage distributors to patch the SANE
> rules right now already).
>
> Would that be OK with you?
Sure, sounds good to me. Just let us know, when this is generally
available in a released version, and we can remove the rule from udev.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH 1/3] Add virtioblk_id tool to extract drive serial numbers
From: Ryan Harper @ 2010-06-14 13:15 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-2-git-send-email-ryanh@us.ibm.com>
* Kay Sievers <kay.sievers@vrfy.org> [2010-06-14 03:55]:
> On Thu, Jun 10, 2010 at 21:16, Ryan Harper <ryanh@us.ibm.com> wrote:
> > Use the 'VBID' virtio-blk ioctl to extract drive serial numbers
> > to be used for building disk/by-id symlinks. After extracting
> > the serial number of the device it prints out the minimum info
> > needed in a similar format to `scsi_id --export` so that the
> > persistent-storage rules can process the serial information.
> >
> > This program depends on the virtio-blk serial device patches posted
> > here[1] being applied to qemu and linux-kernel.
> >
> > Here is what the output looks like:
> >
> > % ./virtioblk_id /dev/vdb
> > ID_VIRTIO=1
> > ID_TYPE=disk
> > ID_SERIAL=QM00001
> > ID_SERIAL_SHORT=QM00001
>
> As requested in the ealier mail. Please provide a good reason why the
> kernel code can not create a "serial" file (or whatever fits your
> needs) in sysfs at the block device.
I didn't see you respond John's email:
http://www.spinics.net/lists/hotplug/msg03869.html
which included quite bit of the gory history on this topic.
>
> Other subsystems are doing the same thing like:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/mmc/core/mmc.c;h‰f7a25b7ac12ab17f7baa9a18e0d980fe1c50eb;hb=HEAD#l270
>
> We don't like to accumulate special purpose tools based on rather
> weird ioctls for newly developed stuff, which can be replaced with a
> few obviously and generally useful lines of code in the kernel driver.
>
> As I think the general direction of solving the problem you describe
> is fundamentally wrong, I'll apply this only, if there are valid
> reasons not to add this to sysfs.
>
> Thanks,
> Kay
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com
^ permalink raw reply
* Re: [PATCH 1/3] Add virtioblk_id tool to extract drive serial numbers
From: Kay Sievers @ 2010-06-14 13:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-2-git-send-email-ryanh@us.ibm.com>
On Mon, Jun 14, 2010 at 15:15, Ryan Harper <ryanh@us.ibm.com> wrote:
> * Kay Sievers <kay.sievers@vrfy.org> [2010-06-14 03:55]:
>> On Thu, Jun 10, 2010 at 21:16, Ryan Harper <ryanh@us.ibm.com> wrote:
>> > Use the 'VBID' virtio-blk ioctl to extract drive serial numbers
>> > to be used for building disk/by-id symlinks. After extracting
>> > the serial number of the device it prints out the minimum info
>> > needed in a similar format to `scsi_id --export` so that the
>> > persistent-storage rules can process the serial information.
>> >
>> > This program depends on the virtio-blk serial device patches posted
>> > here[1] being applied to qemu and linux-kernel.
>> >
>> > Here is what the output looks like:
>> >
>> > % ./virtioblk_id /dev/vdb
>> > ID_VIRTIO=1
>> > ID_TYPE=disk
>> > ID_SERIAL=QM00001
>> > ID_SERIAL_SHORT=QM00001
>>
>> As requested in the ealier mail. Please provide a good reason why the
>> kernel code can not create a "serial" file (or whatever fits your
>> needs) in sysfs at the block device.
>
> I didn't see you respond John's email:
>
> http://www.spinics.net/lists/hotplug/msg03869.html
>
> which included quite bit of the gory history on this topic.
Yeah, and I don't find any reason there, why a sysfs attribute will not work.
Kay
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-14 16:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> Hi,
>
> I have written a driver for xD card reader and xD/SmartMedia FTL that is
> usually mandatory to use with xD cards.
>
> I think this can be added to 80-drivers.rule
> SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
Why does this module not have the proper MODULE_DEVICE() or aliases in
it so that you don't have to manually load the module? This should not
need to be a udev rule.
thanks,
greg k-h
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-14 23:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Mon, 2010-06-14 at 09:46 -0700, Greg KH wrote:
> On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> > Hi,
> >
> > I have written a driver for xD card reader and xD/SmartMedia FTL that is
> > usually mandatory to use with xD cards.
> >
> > I think this can be added to 80-drivers.rule
> > SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
>
> Why does this module not have the proper MODULE_DEVICE() or aliases in
> it so that you don't have to manually load the module? This should not
> need to be a udev rule.
Well mtd system is not using bus model.
However a card needs to be probed (theoteticly) by several high-level
FTL drivers to make one of them to bind to it. (In fact several can bind
at same now, which is both bad and good feature).
I understand that module can have aliases so it can bind to a bus.
Of course I can do a 'request_module', but I think it isn't nice thing
to do.
I can also attach alias to uevent which is sent to udev, but its also
not easy to do with mtd.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-15 3:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 02:55:49AM +0300, Maxim Levitsky wrote:
> On Mon, 2010-06-14 at 09:46 -0700, Greg KH wrote:
> > On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> > > Hi,
> > >
> > > I have written a driver for xD card reader and xD/SmartMedia FTL that is
> > > usually mandatory to use with xD cards.
> > >
> > > I think this can be added to 80-drivers.rule
> > > SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
> >
> > Why does this module not have the proper MODULE_DEVICE() or aliases in
> > it so that you don't have to manually load the module? This should not
> > need to be a udev rule.
>
> Well mtd system is not using bus model.
Why not? It should be fixed to do so.
> However a card needs to be probed (theoteticly) by several high-level
> FTL drivers to make one of them to bind to it. (In fact several can bind
> at same now, which is both bad and good feature).
Then why would you write a rule to automatically load the module on the
system no matter what?
> I understand that module can have aliases so it can bind to a bus.
module aliases are used by modprobe to know what module to load when a
device is found on a bus.
> Of course I can do a 'request_module', but I think it isn't nice thing
> to do.
Agreed. But as it looks like you always want this module loaded, why
not just make it part of your mtd core?
thanks,
greg k-h
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-15 10:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Mon, 2010-06-14 at 20:19 -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 02:55:49AM +0300, Maxim Levitsky wrote:
> > On Mon, 2010-06-14 at 09:46 -0700, Greg KH wrote:
> > > On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> > > > Hi,
> > > >
> > > > I have written a driver for xD card reader and xD/SmartMedia FTL that is
> > > > usually mandatory to use with xD cards.
> > > >
> > > > I think this can be added to 80-drivers.rule
> > > > SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
> > >
> > > Why does this module not have the proper MODULE_DEVICE() or aliases in
> > > it so that you don't have to manually load the module? This should not
> > > need to be a udev rule.
> >
> > Well mtd system is not using bus model.
>
> Why not? It should be fixed to do so.
Of course.
But I currently try to avoid changes that will result in changes in
areas I can't test.
This is one magnitude harder work, and I don't yet feel confident doing
so.
>
> > However a card needs to be probed (theoteticly) by several high-level
> > FTL drivers to make one of them to bind to it. (In fact several can bind
> > at same now, which is both bad and good feature).
>
> Then why would you write a rule to automatically load the module on the
> system no matter what?
>
> > I understand that module can have aliases so it can bind to a bus.
>
> module aliases are used by modprobe to know what module to load when a
> device is found on a bus.
>
> > Of course I can do a 'request_module', but I think it isn't nice thing
> > to do.
>
> Agreed. But as it looks like you always want this module loaded, why
> not just make it part of your mtd core?
Maybe not statically linked in it, but I am not against making mtd core
load all compiled FTL drivers as soon as an mtd device is registred.
David Woodhouse, what do you think about that?
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: New rule for xD FTL driver
From: David Woodhouse @ 2010-06-15 10:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> Maybe not statically linked in it, but I am not against making mtd core
> load all compiled FTL drivers as soon as an mtd device is registred.
>
> David Woodhouse, what do you think about that?
I'm not massively keen on that. An FTL is like a file system. Would you
insist on loading all compiled file systems when an mtd device is
registered?
Would you submit udev patches which auto-load btrfs when a block device
is registered, such as the patch I see in the mail to which I'm
replying?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-15 13:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote:
> On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> > Maybe not statically linked in it, but I am not against making mtd core
> > load all compiled FTL drivers as soon as an mtd device is registred.
> >
> > David Woodhouse, what do you think about that?
>
> I'm not massively keen on that. An FTL is like a file system. Would you
> insist on loading all compiled file systems when an mtd device is
> registered?
>
> Would you submit udev patches which auto-load btrfs when a block device
> is registered, such as the patch I see in the mail to which I'm
> replying?
This is very good point.
The correct solution therefore is to create a new probe tool to look at
new mtd device to see the 'filesystem magic', and them load the
corresponding FTL.
However, this still requires mtdchar or mtdblock be present.
I think its not a bad idea to make mtdchar to load automatically on mtd
device addition, and then bind the prober to creation of /dev/mtd0...
(Which sure will be an udev rule)
This is a bit out of my reach now because I am quite busy with exams, so
for now, it would be nice to have this udev rule (so users won't tell me
that my driver doesn't work), and later I sure fix that.
I will create a prober for all FTLs currently supported by mtd core.
BTW, speaking of the bus model, it won't help at all, because there is
no real bus involved. Probing of the MTD is required anyway.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-15 14:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 04:22:24PM +0300, Maxim Levitsky wrote:
> On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote:
> > On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> > > Maybe not statically linked in it, but I am not against making mtd core
> > > load all compiled FTL drivers as soon as an mtd device is registred.
> > >
> > > David Woodhouse, what do you think about that?
> >
> > I'm not massively keen on that. An FTL is like a file system. Would you
> > insist on loading all compiled file systems when an mtd device is
> > registered?
> >
> > Would you submit udev patches which auto-load btrfs when a block device
> > is registered, such as the patch I see in the mail to which I'm
> > replying?
>
> This is very good point.
> The correct solution therefore is to create a new probe tool to look at
> new mtd device to see the 'filesystem magic', and them load the
> corresponding FTL.
Yes, that sounds like the correct thing to do.
> However, this still requires mtdchar or mtdblock be present.
> I think its not a bad idea to make mtdchar to load automatically on mtd
> device addition, and then bind the prober to creation of /dev/mtd0...
> (Which sure will be an udev rule)
>
> This is a bit out of my reach now because I am quite busy with exams, so
> for now, it would be nice to have this udev rule (so users won't tell me
> that my driver doesn't work), and later I sure fix that.
No, as you pointed out, this is not the correct thing, so why would we
want to add it this way?
thanks,
greg k-h
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-15 15:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 04:22:24PM +0300, Maxim Levitsky wrote:
> > On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote:
> > > On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> > > > Maybe not statically linked in it, but I am not against making mtd core
> > > > load all compiled FTL drivers as soon as an mtd device is registred.
> > > >
> > > > David Woodhouse, what do you think about that?
> > >
> > > I'm not massively keen on that. An FTL is like a file system. Would you
> > > insist on loading all compiled file systems when an mtd device is
> > > registered?
> > >
> > > Would you submit udev patches which auto-load btrfs when a block device
> > > is registered, such as the patch I see in the mail to which I'm
> > > replying?
> >
> > This is very good point.
> > The correct solution therefore is to create a new probe tool to look at
> > new mtd device to see the 'filesystem magic', and them load the
> > corresponding FTL.
>
> Yes, that sounds like the correct thing to do.
>
> > However, this still requires mtdchar or mtdblock be present.
> > I think its not a bad idea to make mtdchar to load automatically on mtd
> > device addition, and then bind the prober to creation of /dev/mtd0...
> > (Which sure will be an udev rule)
> >
> > This is a bit out of my reach now because I am quite busy with exams, so
> > for now, it would be nice to have this udev rule (so users won't tell me
> > that my driver doesn't work), and later I sure fix that.
>
> No, as you pointed out, this is not the correct thing, so why would we
> want to add it this way?
A temporarily solution which is also more or less ok.
I am not writing a rule to load all FTL driver, but only the sm_ftl.
Maybe I write the prober now after all though.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-15 15:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 18:27 +0300, Maxim Levitsky wrote:
> On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote:
> > On Tue, Jun 15, 2010 at 04:22:24PM +0300, Maxim Levitsky wrote:
> > > On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote:
> > > > On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> > > > > Maybe not statically linked in it, but I am not against making mtd core
> > > > > load all compiled FTL drivers as soon as an mtd device is registred.
> > > > >
> > > > > David Woodhouse, what do you think about that?
> > > >
> > > > I'm not massively keen on that. An FTL is like a file system. Would you
> > > > insist on loading all compiled file systems when an mtd device is
> > > > registered?
> > > >
> > > > Would you submit udev patches which auto-load btrfs when a block device
> > > > is registered, such as the patch I see in the mail to which I'm
> > > > replying?
> > >
> > > This is very good point.
> > > The correct solution therefore is to create a new probe tool to look at
> > > new mtd device to see the 'filesystem magic', and them load the
> > > corresponding FTL.
> >
> > Yes, that sounds like the correct thing to do.
> >
> > > However, this still requires mtdchar or mtdblock be present.
> > > I think its not a bad idea to make mtdchar to load automatically on mtd
> > > device addition, and then bind the prober to creation of /dev/mtd0...
> > > (Which sure will be an udev rule)
> > >
> > > This is a bit out of my reach now because I am quite busy with exams, so
> > > for now, it would be nice to have this udev rule (so users won't tell me
> > > that my driver doesn't work), and later I sure fix that.
> >
> > No, as you pointed out, this is not the correct thing, so why would we
> > want to add it this way?
> A temporarily solution which is also more or less ok.
> I am not writing a rule to load all FTL driver, but only the sm_ftl.
> Maybe I write the prober now after all though.
Can udev helper tell udev to load modules by setting some variable?
Because otherwise I would need to export a variable for each FTL, and
have a rule for each such variable to load a module.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-15 15:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 06:27:35PM +0300, Maxim Levitsky wrote:
> On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote:
> > On Tue, Jun 15, 2010 at 04:22:24PM +0300, Maxim Levitsky wrote:
> > > On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote:
> > > > On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> > > > > Maybe not statically linked in it, but I am not against making mtd core
> > > > > load all compiled FTL drivers as soon as an mtd device is registred.
> > > > >
> > > > > David Woodhouse, what do you think about that?
> > > >
> > > > I'm not massively keen on that. An FTL is like a file system. Would you
> > > > insist on loading all compiled file systems when an mtd device is
> > > > registered?
> > > >
> > > > Would you submit udev patches which auto-load btrfs when a block device
> > > > is registered, such as the patch I see in the mail to which I'm
> > > > replying?
> > >
> > > This is very good point.
> > > The correct solution therefore is to create a new probe tool to look at
> > > new mtd device to see the 'filesystem magic', and them load the
> > > corresponding FTL.
> >
> > Yes, that sounds like the correct thing to do.
> >
> > > However, this still requires mtdchar or mtdblock be present.
> > > I think its not a bad idea to make mtdchar to load automatically on mtd
> > > device addition, and then bind the prober to creation of /dev/mtd0...
> > > (Which sure will be an udev rule)
> > >
> > > This is a bit out of my reach now because I am quite busy with exams, so
> > > for now, it would be nice to have this udev rule (so users won't tell me
> > > that my driver doesn't work), and later I sure fix that.
> >
> > No, as you pointed out, this is not the correct thing, so why would we
> > want to add it this way?
> A temporarily solution which is also more or less ok.
If it is "ok", and a "temporary" solution, then just move your kernel
module into the core mtd.ko module and you should be fine.
But odds are, you will not convince the mtd maintainer that's an ok
solution either :)
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox