* Re: udev-161-1 breaks DVD-ROM
From: Martin Pitt @ 2010-08-30 8:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.vh48hu1jee43hi@localhost.localdomain>
Martin Pitt [2010-08-30 10:14 +0200]:
> I can't reproduce that here, so I need further debugging info. Can you
> please give me the output of
>
> /lib/udev/cdrom_id --debug /dev/sr0
>
> with the DVD-ROM in the drive for both version 160 and version 161?
Nevermind, those are already on the downstream bug. Will look there.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: udev-161-1 breaks DVD-ROM
From: Martin Pitt @ 2010-08-30 13:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.vh48hu1jee43hi@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
Hello again,
Борис Васильев [2010-08-28 14:23 +0400]:
> udev version udev-161-1 breaks DVD-ROM functionality on my computer.
> After upgrade, putting in a DVD with data shows up as a blank DVD in GNOME.
So, I looked at the two logs attached on the arch bug report.
Unfortunately the 161-1 log file was done without a medium in the
drive (or you did it too early and the drive didn't finish reading the
disk yet). Can you please re-do the 161-1 log?
But while I looked through the code, I noticed a flaw in the "DVD-RW
ro/seq" patch [1]: It inserts the ro/seq differentiation into
feature_profiles(), but this should just detect the drive
capabilities, not the medium state. I fixed that in [2], but I
suppose this is not the complete fix for that bug yet, since it didn't
break DVD-ROM operations at all, it just falsely claimed that they
were rewritable.
Thanks,
Martin
[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=cf2205a1986222fdc0238190f5742f54d943cd23
[2] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=2458db3edd8d66827b34978ff471dff8f879e9ab
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: udev-161-1 breaks DVD-ROM
From: Martin Pitt @ 2010-08-30 22:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.vh48hu1jee43hi@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
Hello again,
I just committed another fix for sloppy drive firmware, which would
previously lead to considering nonempty DVDs as blank:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=5e267ea5a36de0b2a9a8965ca93dd45bbd6b1a8b
There is quite a high chance that this will fix your problem. Can you
try this (or ask Arch Linux in the downstream report to provide a
matching package for testing)?
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't install systemd scripts with
From: Martin Pitt @ 2010-08-31 6:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1282875003-11074-1-git-send-email-mforney@mforney.org>
Hello Michael,
Michael Forney [2010-08-26 19:10 -0700]:
> Currently, the scripts get installed to /no/ if that option is
> specified.
I can't reproduce this: I tried
./configure --prefix=/usr --without-systemdsystemunitdir
make
make install DESTDIR=/tmp/x/
and I don't get a /tmp/x/no, nor does grepping for SYSTEMD reveal any
assignment to "no".
What's the particular configure command you are using?
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* udev rule file query
From: Martin Payne @ 2010-09-01 15:03 UTC (permalink / raw)
To: linux-hotplug
I have written a UDEV rules file that starts off with the following:
BUS="usb", SYSFS(idVendor)="1234"
My new Linux kernel informs me that BUS and SYSFS will soon be deprecated.
So, I guess I should now use:
SUBSYSTEM="usb", ATTR(idVendor)="1234"
But will this work for older systems? It is not clear to me whether the
SUBSYSTEM and ATTR keywords have been recognised by udev from the beginning.
If not can you tell me when they were introduced?
Martin Payne
Microcosm Ltd
^ permalink raw reply
* Re: udev rule file query
From: Martin Pitt @ 2010-09-01 15:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <002d01cb49e6$da8053e0$8f80fba0$@co.uk>
Hello Martin,
Martin Payne [2010-09-01 16:03 +0100]:
> So, I guess I should now use:
>
> SUBSYSTEM="usb", ATTR(idVendor)="1234"
Right, except that it's written ATTR{}, not ATTR().
> But will this work for older systems? It is not clear to me whether the
> SUBSYSTEM and ATTR keywords have been recognised by udev from the beginning.
Not from the beginning, but NEWS documents this pretty well:
---------------- 8< ----------------
udev 098
====
Bugfixes.
Renaming of some key names (the old names still work):
BUS -> SUBSYSTEMS, ID -> KERNELS, SYSFS -> ATTRS, DRIVER -> DRIVERS.
[...]
---------------- 8< ----------------
098 was released in August 2006, so in software terms SUBSYSTEM and
ATTR have been around for ages.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH] Don't install systemd scripts with --without-systemdsystemunitdir
From: Michael Forney @ 2010-09-02 5:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1282875003-11074-1-git-send-email-mforney@mforney.org>
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
Excerpts from Martin Pitt's message of Mon Aug 30 23:58:47 -0700 2010:
> Hello Michael,
>
> Michael Forney [2010-08-26 19:10 -0700]:
> > Currently, the scripts get installed to /no/ if that option is
> > specified.
>
> I can't reproduce this: I tried
>
> ./configure --prefix=/usr --without-systemdsystemunitdir
> make
> make install DESTDIR=/tmp/x/
>
> and I don't get a /tmp/x/no, nor does grepping for SYSTEMD reveal any
> assignment to "no".
>
> What's the particular configure command you are using?
>
> Martin
Hi Martin,
I am not sure why you are having trouble reproducing it. I ran the same
commands and still saw the issue I described. I have attached a log for
reference.
Logically though, what is happening is when
--without-systemdsystemunitdir gets passed to configure,
with_systemdsystemunitdir gets assigned the value 'no'. Configure then
checks if this string is non-zero (which it is), and enables
WITH_SYSTEMD. This causes the scripts to get installed to the directory
$(systemdsystemunitdir) which is 'no'.
This seems to be a problem with several projects using this option,
including NetworkManager, which has been fixed
(https://bugzilla.gnome.org/show_bug.cgi?id=628439), and dbus, which has
been not yet commented on
(https://bugs.freedesktop.org/attachment.cgi?id=38319).
I just tested this with master and I still see the problem. Are you sure
your build directory is clean?
Thanks for taking the time to look at my patch!
--
Michael Forney <mforney@mforney.org>
[-- Attachment #2: udev.log --]
[-- Type: application/octet-stream, Size: 29356 bytes --]
^ permalink raw reply
* Re: Do not create persistent name rules for KVM network interfaces
From: Martin Pitt @ 2010-09-02 6:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100827163550.GA30688@bongo.bofh.it>
Hello Marco,
Marco d'Itri [2010-08-27 18:35 +0200]:
> Do not create persistent name rules for KVM network interfaces.
>
> The virtual interfaces created by KVM are stable, 54:52:00 is the MAC-48
> range of KVM: http://www.coffer.com/mac_find/?stringT5200 .
Thanks for this. This got committed yesterday. However, it seems that
coffer.com is wrong: When I boot kvm, I really get a 52:54:00:*
address. Please see the qemu git for this:
http://git.savannah.gnu.org/cgit/qemu.git/tree/net.c#n796
I pushed that as c03180194cb62cda286efcc1563391a1408394ff.
For VMWare, all the google hits seem to agree to each other
(00:0c:29:* and 00:50:56:*), so I committed that as well in
d4de0a0321b471e9dd8c32f1f3266b0b466457c7. Xen already seems covered,
so I didn't add a filter for those.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH] Don't install systemd scripts with
From: Martin Pitt @ 2010-09-02 6:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1282875003-11074-1-git-send-email-mforney@mforney.org>
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
Hello Michael,
Michael Forney [2010-09-01 22:43 -0700]:
> I am not sure why you are having trouble reproducing it. I ran the same
> commands and still saw the issue I described. I have attached a log for
> reference.
Ah, it seems that you are using an older autoconf and automake; I
already get the non-verbose output by default, like
CC libudev/libudev-util.lo
and no trace of /no/. I suppose the newer auto* tools just fixed this
once and for all.
Anyway, stuff still works with your patch (I tested both --without and
with an actual directory), so I applied it. Thanks!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Do not create persistent name rules for KVM network interfaces
From: Marco d'Itri @ 2010-09-02 8:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100827163550.GA30688@bongo.bofh.it>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Sep 02, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Thanks for this. This got committed yesterday. However, it seems that
> coffer.com is wrong: When I boot kvm, I really get a 52:54:00:*
> address. Please see the qemu git for this:
Maybe we need both? I am quite sure that my KVM guests running on RHEL
hosts get 54:52:00:*.
OTOH, I do not know what sets the MAC address in the provisioning
process.
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Do not create persistent name rules for KVM network interfaces
From: Martin Pitt @ 2010-09-02 9:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100827163550.GA30688@bongo.bofh.it>
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
Hello Marco,
Marco d'Itri [2010-09-02 10:32 +0200]:
> Maybe we need both? I am quite sure that my KVM guests running on RHEL
> hosts get 54:52:00:*.
OK, sorry for second-guessing you then. When using 100% accurate and
reliable statistical methods [1] *cough* *cough* it seems that 54:52:*
is not unheard of indeed, so I just added it as an alternative now in
[2].
Thanks,
Martin
[1] http://www.googlefight.com/index.php?lang=en_GB&word1=kvm+mac+52%3A54&word2=kvm+mac+54%3A52
[2] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=634afac119bbe6bc21719ae3daa45805b1cf3334
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Do not create persistent name rules for KVM network interfaces
From: Jim Paris @ 2010-09-02 19:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100827163550.GA30688@bongo.bofh.it>
Martin Pitt wrote:
> Hello Marco,
>
> Marco d'Itri [2010-09-02 10:32 +0200]:
> > Maybe we need both? I am quite sure that my KVM guests running on RHEL
> > hosts get 54:52:00:*.
>
> OK, sorry for second-guessing you then. When using 100% accurate and
> reliable statistical methods [1] *cough* *cough* it seems that 54:52:*
> is not unheard of indeed, so I just added it as an alternative now in
> [2].
Hi,
It looks like virt-install is the program that had the wrong prefix at
one point, fixed by this commit:
http://hg.fedorahosted.org/hg/python-virtinst/diff/a3334a88986f/virtinst/util.py
-jim
^ permalink raw reply
* [PATCH] Minor ChangeLog fix
From: Michal Soltys @ 2010-09-02 22:23 UTC (permalink / raw)
To: linux-hotplug
In v141 -> v142 entry, there's a note about udevd creating
/dev/{null,kmsg,console}. It was added in commit 540f46698dd5a3b,
but shortly after that removed in a00bdfa16b9bac7 before v142
release.
Signed-off-by: Michal Soltys <soltys@ziu.info>
---
ChangeLog | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 683a1de..01e9a79 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1024,7 +1024,6 @@ Kay Sievers (46):
test-libudev: update monitor source
TODO: add packet filter
update NEWS
- udevd: at startup create /dev/null, /dev/console, /dev/kmsg
cdrom_id: add and use ID_CDROM_MEDIA to decide if we run vol_id
libudev: monitor - add client socket filter for subsystem value
udevadm: monitor - print error if we can not bind to socket
--
1.7.2.1
^ permalink raw reply related
* Re: [PATCH] Minor ChangeLog fix
From: Kay Sievers @ 2010-09-03 8:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100902222325.GA29642@mott.hasevolq.tld>
On Fri, Sep 3, 2010 at 00:23, Michal Soltys <soltys@ziu.info> wrote:
> In v141 -> v142 entry, there's a note about udevd creating
> /dev/{null,kmsg,console}. It was added in commit 540f46698dd5a3b,
> but shortly after that removed in a00bdfa16b9bac7 before v142
> release.
Applied.
Thanks,
Kay
^ permalink raw reply
* Re: Do not create persistent name rules for KVM network interfaces
From: Kay Sievers @ 2010-09-03 12:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100827163550.GA30688@bongo.bofh.it>
On Thu, Sep 2, 2010 at 21:00, Jim Paris <jim@jtan.com> wrote:
> It looks like virt-install is the program that had the wrong prefix at
> one point, fixed by this commit:
> Â http://hg.fedorahosted.org/hg/python-virtinst/diff/a3334a88986f/virtinst/util.py
Ah, nice. I've switched back to the single match now.
Thanks a lot for solving this mystery. :
Cheers,
Kay
^ permalink raw reply
* [PATCH] scsi_id: Export target port group
From: Hannes Reinecke @ 2010-09-06 9:00 UTC (permalink / raw)
To: linux-hotplug
For ALUA support it's useful to have the target port group number
of a device. Export it.
Signed-off-by: Hannes Reinecke <hare@suse.de>
diff --git a/extras/scsi_id/scsi.h b/extras/scsi_id/scsi.h
index f5aa686..8e9ce40 100644
--- a/extras/scsi_id/scsi.h
+++ b/extras/scsi_id/scsi.h
@@ -54,6 +54,11 @@ struct scsi_ioctl_command {
#define SCSI_ID_T10_VENDOR 1
#define SCSI_ID_EUI_64 2
#define SCSI_ID_NAA 3
+#define SCSI_ID_RELPORT 4
+#define SCSI_ID_TGTGROUP 5
+#define SCSI_ID_LUNGROUP 6
+#define SCSI_ID_MD5 7
+#define SCSI_ID_NAME 8
/*
* Supported NAA values. These fit in 4 bits, so the "don't care" value
diff --git a/extras/scsi_id/scsi_id.c b/extras/scsi_id/scsi_id.c
index 3811ea5..6c88265 100644
--- a/extras/scsi_id/scsi_id.c
+++ b/extras/scsi_id/scsi_id.c
@@ -575,6 +575,9 @@ static int scsi_id(struct udev *udev, char *maj_min_dev)
printf("ID_WWN_WITH_EXTENSION=0x%s\n", dev_scsi.wwn);
}
}
+ if (dev_scsi.tgpt_group[0] != '\0') {
+ printf("ID_TARGET_PORT=%s\n", dev_scsi.tgpt_group);
+ }
if (dev_scsi.unit_serial_number[0] != '\0') {
printf("ID_SCSI_SERIAL=%s\n", dev_scsi.unit_serial_number);
}
diff --git a/extras/scsi_id/scsi_id.h b/extras/scsi_id/scsi_id.h
index 4475eac..f6c269f 100644
--- a/extras/scsi_id/scsi_id.h
+++ b/extras/scsi_id/scsi_id.h
@@ -53,6 +53,9 @@ struct scsi_id_device {
/* NULs if not set - otherwise hex encoding using lower-case e.g. '0xe00000d80000' */
char wwn_vendor_extension[17];
+
+ /* NULs if not set - otherwise decimal number */
+ char tgpt_group[8];
};
extern int scsi_std_inquiry(struct udev *udev, struct scsi_id_device *dev_scsi, const char *devname);
diff --git a/extras/scsi_id/scsi_serial.c b/extras/scsi_id/scsi_serial.c
index dd5e1fd..6f5da37 100644
--- a/extras/scsi_id/scsi_serial.c
+++ b/extras/scsi_id/scsi_serial.c
@@ -48,6 +48,7 @@
* is normally one or some small number of descriptors.
*/
static const struct scsi_id_search_values id_search_list[] = {
+ { SCSI_ID_TGTGROUP, SCSI_ID_NAA_DONT_CARE, SCSI_ID_BINARY },
{ SCSI_ID_NAA, SCSI_ID_NAA_IEEE_REG_EXTENDED, SCSI_ID_BINARY },
{ SCSI_ID_NAA, SCSI_ID_NAA_IEEE_REG_EXTENDED, SCSI_ID_ASCII },
{ SCSI_ID_NAA, SCSI_ID_NAA_IEEE_REG, SCSI_ID_BINARY },
@@ -485,16 +486,20 @@ static int check_fill_0x83_id(struct udev *udev,
struct scsi_id_device *dev_scsi,
unsigned char *page_83,
const struct scsi_id_search_values
- *id_search, char *serial, char *serial_short, int max_len,
- char *wwn,
- char *wwn_vendor_extension)
+ *id_search, char *serial, char *serial_short,
+ int max_len, char *wwn,
+ char *wwn_vendor_extension, char *tgpt_group)
{
int i, j, s, len;
/*
* ASSOCIATION must be with the device (value 0)
+ * or with the target port for SCSI_ID_TGTPORT
*/
- if ((page_83[1] & 0x30) != 0)
+ if (page_83[1] & 0x30 = 0x10)
+ if (id_search->id_type != SCSI_ID_TGTGROUP)
+ return 1;
+ else if ((page_83[1] & 0x30) != 0)
return 1;
if ((page_83[1] & 0x0f) != id_search->id_type)
@@ -536,6 +541,14 @@ static int check_fill_0x83_id(struct udev *udev,
return 1;
}
+ if (id_search->id_type = SCSI_ID_TGTGROUP && tgpt_group != NULL) {
+ unsigned int group;
+
+ group = ((unsigned int)page_83[6] << 8) | page_83[7];
+ sprintf(tgpt_group,"%x", group);
+ return 1;
+ }
+
serial[0] = hex_str[id_search->id_type];
/*
@@ -572,12 +585,13 @@ static int check_fill_0x83_id(struct udev *udev,
strcpy(serial_short, &serial[s]);
- if (id_search->id_type = SCSI_ID_NAA && wwn != NULL) {
- strncpy(wwn, &serial[s], 16);
+ if (id_search->id_type = SCSI_ID_NAA && wwn != NULL) {
+ strncpy(wwn, &serial[s], 16);
if (wwn_vendor_extension != NULL) {
strncpy(wwn_vendor_extension, &serial[s + 16], 16);
}
- }
+ }
+
return 0;
}
@@ -609,14 +623,14 @@ static int check_fill_0x83_prespc3(struct udev *udev,
static int do_scsi_page83_inquiry(struct udev *udev,
struct scsi_id_device *dev_scsi, int fd,
char *serial, char *serial_short, int len,
- char *unit_serial_number, char *wwn,
- char *wwn_vendor_extension)
+ char *unit_serial_number, char *wwn,
+ char *wwn_vendor_extension, char *tgpt_group)
{
int retval;
unsigned int id_ind, j;
unsigned char page_83[SCSI_INQ_BUFF_LEN];
- /* also pick up the page 80 serial number */
+ /* also pick up the page 80 serial number */
do_scsi_page80_inquiry(udev, dev_scsi, fd, NULL, unit_serial_number, MAX_SERIAL_LEN);
memset(page_83, 0, SCSI_INQ_BUFF_LEN);
@@ -680,8 +694,8 @@ static int do_scsi_page83_inquiry(struct udev *udev,
dev_scsi, &page_83[j],
&id_search_list[id_ind],
serial, serial_short, len,
- wwn,
- wwn_vendor_extension);
+ wwn, wwn_vendor_extension,
+ tgpt_group);
dbg(udev, "%s id desc %d/%d/%d\n", dev_scsi->kernel,
id_search_list[id_ind].id_type,
id_search_list[id_ind].naa_type,
@@ -895,7 +909,7 @@ int scsi_get_serial(struct udev *udev,
goto completed;
}
} else if (page_code = PAGE_83) {
- if (do_scsi_page83_inquiry(udev, dev_scsi, fd, dev_scsi->serial, dev_scsi->serial_short, len, dev_scsi->unit_serial_number, dev_scsi->wwn, dev_scsi->wwn_vendor_extension)) {
+ if (do_scsi_page83_inquiry(udev, dev_scsi, fd, dev_scsi->serial, dev_scsi->serial_short, len, dev_scsi->unit_serial_number, dev_scsi->wwn, dev_scsi->wwn_vendor_extension, dev_scsi->tgpt_group)) {
retval = 1;
goto completed;
} else {
@@ -911,7 +925,7 @@ int scsi_get_serial(struct udev *udev,
* conform to pre-SPC3 expectations.
*/
if (retval = 2) {
- if (do_scsi_page83_inquiry(udev, dev_scsi, fd, dev_scsi->serial, dev_scsi->serial_short, len, dev_scsi->unit_serial_number, dev_scsi->wwn, dev_scsi->wwn_vendor_extension)) {
+ if (do_scsi_page83_inquiry(udev, dev_scsi, fd, dev_scsi->serial, dev_scsi->serial_short, len, dev_scsi->unit_serial_number, dev_scsi->wwn, dev_scsi->wwn_vendor_extension, dev_scsi->tgpt_group)) {
retval = 1;
goto completed;
} else {
@@ -951,7 +965,7 @@ int scsi_get_serial(struct udev *udev,
for (ind = 4; ind <= page0[3] + 3; ind++)
if (page0[ind] = PAGE_83)
if (!do_scsi_page83_inquiry(udev, dev_scsi, fd,
- dev_scsi->serial, dev_scsi->serial_short, len, dev_scsi->unit_serial_number, dev_scsi->wwn, dev_scsi->wwn_vendor_extension)) {
+ dev_scsi->serial, dev_scsi->serial_short, len, dev_scsi->unit_serial_number, dev_scsi->wwn, dev_scsi->wwn_vendor_extension, dev_scsi->tgpt_group)) {
/*
* Success
*/
^ permalink raw reply related
* [ANNOUNCE] udev 162 release
From: Kay Sievers @ 2010-09-07 4:42 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 162
====
Bugfixes.
Persistent network naming rules are disabled inside of Qemu/KVM now.
New and updated keymaps.
Udev gets unconditionally enabled on systemd installations now. There
is no longer the need to to run 'systemctl enable udev.service'.
^ permalink raw reply
* Re: [PATCH] scsi_id: Export target port group
From: Kay Sievers @ 2010-09-07 6:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100906090022.22A0B352D8@ochil.suse.de>
On Mon, Sep 6, 2010 at 11:00, Hannes Reinecke <hare@suse.de> wrote:
>
> For ALUA support it's useful to have the target port group number
> of a device. Export it.
Applied.
Thanks,
Kay
^ permalink raw reply
* Use GROUP= in a rule matching an interface of the device?
From: Ludovic Rousseau @ 2010-09-09 9:21 UTC (permalink / raw)
To: linux-hotplug
Hello,
I am trying to write a udev configuration file to change the group
ownership of the device if the device contains a CCID interface
(bInterfaceClass = 11 or 0x0B).
I would like to use something like:
ATTR{bInterfaceClass}="0b", GROUP="pcscd"
but that does not work.
I also tried ATTRS instead of ATTR
ATTRS{bInterfaceClass}="0b", GROUP="pcscd"
but it does not work either.
One solution I found to work is:
ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
It looks like the problem is that my rule matches on an attribute of
an interface instead of an attribute of the device.
Is it possible/supported to use GROUP= in my case?
Thanks
Some more info:
Debian testing/squeeze system
kernel 2.6.34-1-686
udev 160-1
$ udevadm monitor --env --kernel --udev
KERNEL[1284023092.630235] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1
SUBSYSTEM=usb
DEVNAME=bus/usb/003/035
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
BUSNUM\03
DEVNUM\x035
SEQNUM\x1538
MAJOR\x189
MINOR)0
KERNEL[1284023092.633197] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
INTERFACE\x11/0/0
MODALIAS=usb:v08E6p3437d0100dc00dsc00dp00ic0Bisc00ip00
SEQNUM\x1539
UDEV [1284023092.642405] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/003/035
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
BUSNUM\03
DEVNUM\x035
SEQNUM\x1538
ID_VENDOR=Gemplus
ID_VENDOR_ENC=Gemplus
ID_VENDOR_ID\be6
ID_MODEL=USB_SmartCard_Reader
ID_MODEL_ENC=USB\x20SmartCard\x20Reader
ID_MODEL_ID437
ID_REVISION\x0100
ID_SERIAL=Gemplus_USB_SmartCard_Reader
ID_BUS=usb
ID_USB_INTERFACES=:0b0000:
MAJOR\x189
MINOR)0
DEVLINKS=/dev/char/189:290
UDEV [1284023092.663831] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
INTERFACE\x11/0/0
MODALIAS=usb:v08E6p3437d0100dc00dsc00dp00ic0Bisc00ip00
SEQNUM\x1539
$ udevadm info --path /devices/pci0000:00/0000:00:1d.1/usb3/3-1 --attribute-walk
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
KERNEL="3-1"
SUBSYSTEM="usb"
DRIVER="usb"
ATTR{configuration}=""
ATTR{bNumInterfaces}=" 1"
ATTR{bConfigurationValue}="1"
ATTR{bmAttributes}="e0"
ATTR{bMaxPower}="100mA"
ATTR{urbnum}="756"
ATTR{idVendor}="04cc"
ATTR{idProduct}="1122"
ATTR{bcdDevice}="0110"
ATTR{bDeviceClass}="09"
ATTR{bDeviceSubClass}="00"
ATTR{bDeviceProtocol}="00"
ATTR{bNumConfigurations}="1"
ATTR{bMaxPacketSize0}="64"
ATTR{speed}="12"
ATTR{busnum}="3"
ATTR{devnum}="2"
ATTR{devpath}="1"
ATTR{version}=" 1.10"
ATTR{maxchild}="5"
ATTR{quirks}="0x0"
ATTR{avoid_reset_quirk}="0"
ATTR{authorized}="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3':
KERNELS="usb3"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="e0"
ATTRS{bMaxPower}=" 0mA"
ATTRS{urbnum}="34"
ATTRS{idVendor}="1d6b"
ATTRS{idProduct}="0001"
ATTRS{bcdDevice}="0206"
ATTRS{bDeviceClass}="09"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="00"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="64"
ATTRS{speed}="12"
ATTRS{busnum}="3"
ATTRS{devnum}="1"
ATTRS{devpath}="0"
ATTRS{version}=" 1.10"
ATTRS{maxchild}="2"
ATTRS{quirks}="0x0"
ATTRS{avoid_reset_quirk}="0"
ATTRS{authorized}="1"
ATTRS{manufacturer}="Linux 2.6.34-1-686 uhci_hcd"
ATTRS{product}="UHCI Host Controller"
ATTRS{serial}="0000:00:1d.1"
ATTRS{authorized_default}="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.1':
KERNELS="0000:00:1d.1"
SUBSYSTEMS="pci"
DRIVERS="uhci_hcd"
ATTRS{vendor}="0x8086"
ATTRS{device}="0x27c9"
ATTRS{subsystem_vendor}="0x1028"
ATTRS{subsystem_device}="0x01ad"
ATTRS{class}="0x0c0300"
ATTRS{irq}="22"
ATTRS{local_cpus}="ffffffff"
ATTRS{local_cpulist}="0-31"
ATTRS{modalias}="pci:v00008086d000027C9sv00001028sd000001ADbc0Csc03i00"
ATTRS{dma_mask_bits}="32"
ATTRS{consistent_dma_mask_bits}="32"
ATTRS{broken_parity_status}="0"
ATTRS{msi_bus}=""
looking at parent device '/devices/pci0000:00':
KERNELS="pci0000:00"
SUBSYSTEMS=""
DRIVERS=""
$ udevadm info --path
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0
--attribute-walk
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0':
KERNEL="3-1.1:1.0"
SUBSYSTEM="usb"
DRIVER=""
ATTR{bInterfaceNumber}="00"
ATTR{bAlternateSetting}=" 0"
ATTR{bNumEndpoints}="03"
ATTR{bInterfaceClass}="0b"
ATTR{bInterfaceSubClass}="00"
ATTR{bInterfaceProtocol}="00"
ATTR{modalias}="usb:v08E6p3437d0100dc00dsc00dp00ic0Bisc00ip00"
ATTR{supports_autosuspend}="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1':
KERNELS="3-1.1"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="a0"
ATTRS{bMaxPower}="200mA"
ATTRS{urbnum}="9"
ATTRS{idVendor}="08e6"
ATTRS{idProduct}="3437"
ATTRS{bcdDevice}="0100"
ATTRS{bDeviceClass}="00"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="00"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="8"
ATTRS{speed}="12"
ATTRS{busnum}="3"
ATTRS{devnum}="35"
ATTRS{devpath}="1.1"
ATTRS{version}=" 1.10"
ATTRS{maxchild}="0"
ATTRS{quirks}="0x0"
ATTRS{avoid_reset_quirk}="0"
ATTRS{authorized}="1"
ATTRS{manufacturer}="Gemplus"
ATTRS{product}="USB SmartCard Reader"
looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
KERNELS="3-1"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="e0"
ATTRS{bMaxPower}="100mA"
ATTRS{urbnum}="756"
ATTRS{idVendor}="04cc"
ATTRS{idProduct}="1122"
ATTRS{bcdDevice}="0110"
ATTRS{bDeviceClass}="09"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="00"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="64"
ATTRS{speed}="12"
ATTRS{busnum}="3"
ATTRS{devnum}="2"
ATTRS{devpath}="1"
ATTRS{version}=" 1.10"
ATTRS{maxchild}="5"
ATTRS{quirks}="0x0"
ATTRS{avoid_reset_quirk}="0"
ATTRS{authorized}="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3':
KERNELS="usb3"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="e0"
ATTRS{bMaxPower}=" 0mA"
ATTRS{urbnum}="34"
ATTRS{idVendor}="1d6b"
ATTRS{idProduct}="0001"
ATTRS{bcdDevice}="0206"
ATTRS{bDeviceClass}="09"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="00"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="64"
ATTRS{speed}="12"
ATTRS{busnum}="3"
ATTRS{devnum}="1"
ATTRS{devpath}="0"
ATTRS{version}=" 1.10"
ATTRS{maxchild}="2"
ATTRS{quirks}="0x0"
ATTRS{avoid_reset_quirk}="0"
ATTRS{authorized}="1"
ATTRS{manufacturer}="Linux 2.6.34-1-686 uhci_hcd"
ATTRS{product}="UHCI Host Controller"
ATTRS{serial}="0000:00:1d.1"
ATTRS{authorized_default}="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.1':
KERNELS="0000:00:1d.1"
SUBSYSTEMS="pci"
DRIVERS="uhci_hcd"
ATTRS{vendor}="0x8086"
ATTRS{device}="0x27c9"
ATTRS{subsystem_vendor}="0x1028"
ATTRS{subsystem_device}="0x01ad"
ATTRS{class}="0x0c0300"
ATTRS{irq}="22"
ATTRS{local_cpus}="ffffffff"
ATTRS{local_cpulist}="0-31"
ATTRS{modalias}="pci:v00008086d000027C9sv00001028sd000001ADbc0Csc03i00"
ATTRS{dma_mask_bits}="32"
ATTRS{consistent_dma_mask_bits}="32"
ATTRS{broken_parity_status}="0"
ATTRS{msi_bus}=""
looking at parent device '/devices/pci0000:00':
KERNELS="pci0000:00"
SUBSYSTEMS=""
DRIVERS=""
--
Dr. Ludovic Rousseau
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Kay Sievers @ 2010-09-09 9:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
On Thu, Sep 9, 2010 at 11:21, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> I am trying to write a udev configuration file to change the group
> ownership of the device if the device contains a CCID interface
> (bInterfaceClass = 11 or 0x0B).
>
> I would like to use something like:
> ATTR{bInterfaceClass}="0b", GROUP="pcscd"
> but that does not work.
That not possible. Udev can only match on properties of the device
ATTR or a parent device ATTRS.
The device node you want to set the group to is the usb_device, but
the match you want to do is on the usb_interface. At the moment the
usb_device event is handled, the usb_interface does not exist, so this
can never match. And from the usb_interface, which is a children and
comes after the usb_device, you can not change the parent device node.
Udev parses the usb descriptors and makes them available in a
property. That's the only way to access usb_interface properties from
the usb_device event.
Something like:
SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
should do it.
Kay
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Ludovic Rousseau @ 2010-09-09 9:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
> On Thu, Sep 9, 2010 at 11:21, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> I am trying to write a udev configuration file to change the group
>> ownership of the device if the device contains a CCID interface
>> (bInterfaceClass = 11 or 0x0B).
>>
>> I would like to use something like:
>> ATTR{bInterfaceClass}="0b", GROUP="pcscd"
>> but that does not work.
>
> That not possible. Udev can only match on properties of the device
> ATTR or a parent device ATTRS.
>
> The device node you want to set the group to is the usb_device, but
> the match you want to do is on the usb_interface. At the moment the
> usb_device event is handled, the usb_interface does not exist, so this
> can never match. And from the usb_interface, which is a children and
> comes after the usb_device, you can not change the parent device node.
>
> Udev parses the usb descriptors and makes them available in a
> property. That's the only way to access usb_interface properties from
> the usb_device event.
>
> Something like:
> SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
> should do it.
Yes, it does work.
But I find the rule more obscure.
Since performance is not a critical point for me I think I will stay with:
ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
Thanks
--
Dr. Ludovic Rousseau
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: David Zeuthen @ 2010-09-09 20:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
Hey,
On Thu, Sep 9, 2010 at 5:57 AM, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> > Something like:
> > SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
> > should do it.
>
> Yes, it does work.
>
> But I find the rule more obscure.
>
> Since performance is not a critical point for me I think I will stay with:
> ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
Please don't. It's racy. In particular it will break if you have
daemons or apps listening for uevents and doing stuff when the device
node appears.
David
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Ludovic Rousseau @ 2010-09-10 9:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
2010/9/9 David Zeuthen <zeuthen@gmail.com>:
> Hey,
>
> On Thu, Sep 9, 2010 at 5:57 AM, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> > Something like:
>> > SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>> > should do it.
>>
>> Yes, it does work.
>>
>> But I find the rule more obscure.
>>
>> Since performance is not a critical point for me I think I will stay with:
>> ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
>
> Please don't. It's racy. In particular it will break if you have
> daemons or apps listening for uevents and doing stuff when the device
> node appears.
Would the race issue disappear if I use RUN= instead of RUN+=?
The chgrp command should not take to long to execute.
Yes, I also have a daemon listening for events. I am using libhal now
but plan to move to libudev "soon".
Thanks
--
Dr. Ludovic Rousseau
^ permalink raw reply
* [PATCH] rules: add udev rule for ath9k_htc (AR7010) device
From: Rajkumar Manoharan @ 2010-09-10 10:57 UTC (permalink / raw)
To: linux-hotplug
AR7010 cards detected as USB Mass storage mode by default and an eject
command is required to switch to wireless mode.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
rules/rules.d/60-persistent-storage.rules | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/rules/rules.d/60-persistent-storage.rules b/rules/rules.d/60-persistent-storage.rules
index 6449e07..16c2fb1 100644
--- a/rules/rules.d/60-persistent-storage.rules
+++ b/rules/rules.d/60-persistent-storage.rules
@@ -74,4 +74,6 @@ ENV{ID_FS_USAGE}="filesystem|other", ENV{ID_FS_LABEL_ENC}="?*", SYMLINK+="disk
ENV{DEVTYPE}="disk", ENV{ID_WWN_WITH_EXTENSION}="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}"
ENV{DEVTYPE}="partition", ENV{ID_WWN_WITH_EXTENSION}="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}-part%n"
+# eject atheros usb mass storage device
+SUBSYSTEM="block", ENV{DEVTYPE}="disk", ENV{ID_VENDOR}="Virtual", ENV{ID_VENDOR_ID}="0cf3", RUN+="/usr/bin/eject /dev/%k"
LABEL="persistent_storage_end"
--
1.7.2.3
^ permalink raw reply related
* Re: Use GROUP= in a rule matching an interface of the device?
From: Marco d'Itri @ 2010-09-10 11:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
On Sep 10, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:
> Would the race issue disappear if I use RUN= instead of RUN+=?
No. Please use GROUP, it works and is actually easier to understand what
it does.
--
ciao,
Marco
^ 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