Kay Sievers | 7 Oct 15:07

[ANNOUNCE] udev 130 release

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 130
========
Bugfixes.

Kernel devices and device nodes are connected now by reverse indices in
/sys and /dev. A device number retrieved by a stat() or similar, the
kernel device directory can be found by looking up:
  /sys/dev/{block,char}/<maj>:<min>
and the device node of the same device by looking up:
  /dev/{block,char}/<maj>:<min>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mikael Magnusson | 3 Oct 22:30

udev 129 says it supports linux 2.6.19 but prints a warning

I just updated udev to 129 and got this,
  udev: deprecated sysfs layout (CONFIG_SYSFS_DEPRECATED) is unsupported
However, I have no such option in my kernel config (2.6.19). I assume this
means 2.6.19 will soon not be supported in udev. It would perhaps be nice
if the message said which kernel version would be required after the
deprecation, and how far in the future this will happen?

--

-- 
Mikael Magnusson

PS I'm not subscribed.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Peter | 2 Oct 23:07

udev doesn't detect ddf-format raid array

Hi!

I have an adaptec hostraid controller (fakeraid) with 2 drives connected in a 
RAID1 array (metadata is in DDF format) which is nicely detected and enabled 
by dmraid, there is no problem with it after it's enabled.

Recently debian's dmraid-booter has switched to use udev. But udev does not 
detect my drives as raid type, ID_FS_USAGE is missing from the drive info (it 
should be "raid"), so the result is that dmraid does not called at boot. Also 
vol_id sees the partitions as normal partitions.

I've recognised that one of my disks has a HPA, the other hasn't. I'm not sure 
if this has any effect, but because of this, the DDF1-headers are not at the 
same position on the 2 drives.

Below are some outputs. The last one is a 'dmraid -n' output, and what is 
strange for me at first sight is that both drives has 2 DDF1-headers. Is this 
normal? Or do you think I should try to rebuild the raid array with the bios 
utility (maybe after some bios upgrade)? Or is this rather an udev problem?

Thanks,
Peter

$ udevinfo --query=all --name=sda
P: /block/sda
N: sda
S: disk/by-id/ata-SAMSUNG_SP2004C_S07GJ1LYB11332
S: disk/by-id/scsi-SATA_SAMSUNG_SP2004CS07GJ1LYB11332
S: disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0
E: ID_VENDOR=ATA
(Continue reading)

Alan Jenkins | 2 Oct 18:25

[PATCH] selinux: fix 'defined but not used' warning

selinux is initialized lazily, so if selinux is disabled then selinux_init will never be called.

This lets udev compile with -Werror again.

Signed-off-by: Alan Jenkins <alan-jenkins <at> tuffmail.co.uk>

diff --git a/udev/lib/libudev.c b/udev/lib/libudev.c
index c2c5025..16cf860 100644
--- a/udev/lib/libudev.c
+++ b/udev/lib/libudev.c
@@ -72,9 +72,9 @@ static void log_stderr(struct udev *udev,
 	vfprintf(stderr, format, args);
 }

+#ifdef USE_SELINUX
 static void selinux_init(struct udev *udev)
 {
-#ifdef USE_SELINUX
 	/*
 	 * record the present security context, for file-creation
 	 * restoration creation purposes.
@@ -89,8 +89,8 @@ static void selinux_init(struct udev *udev)
 		}
 	}
 	udev->selinux_initialized = 1;
-#endif
 }
+#endif

 void *udev_get_userdata(struct udev *udev)
(Continue reading)

udev-129 compile error with --disable-logging

Hi there!

It seems udev-129 has some log-related name conflicts when compiling udev 
configured with --disable-logging

libudev-ctrl.c: In function 'udev_ctrl_enable_receiving':
libudev-ctrl.c:104: error: called object 'log_null' is not a function
libudev-ctrl.c: In function 'ctrl_send':
libudev-ctrl.c:161: error: called object 'log_null' is not a function

The original source is this:
<<<<<<<<<<<<<<<<<<<<<<
int udev_ctrl_enable_receiving(struct udev_ctrl *uctrl)
{
        int err;
        const int feature_on = 1;

        err= bind(uctrl->sock, (struct sockaddr *)&uctrl->saddr, 
uctrl->addrlen);
        if (err < 0) {
                err(uctrl->udev, "bind failed: %m\n");
                return err;
        }

        /* enable receiving of the sender credentials */
        setsockopt(uctrl->sock, SOL_SOCKET, SO_PASSCRED, &feature_on, 
sizeof(feature_on));
        return 0;
}
<<<<<<<<<<<<<<<<<<<<<<
(Continue reading)

Kay Sievers | 1 Oct 22:43

[ANNOUNCE] udev 129 release

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 129
========
Fix recently introduced bug, which caused a compilation without large
file support, where vol_id does not recognize raid signatures at the end
of a volume.

Firewire disks now create both, by-id/scsi-* and by-id/ieee-* links.
Seems some kernel versions prevent the creation of the ieee-* links,
so people used the scsi-* link which disappeared now.

More libudev work. Almost all udevadm functionality comes from libudev
now.

udevadm trigger has a new option --type, which allows to trigger events
for "devices", for "subsystems", or "failed" devices. The old option
--retry-failed" still works, but is no longer mentioned in the man page.

--
(Continue reading)

Chris Spiegel | 1 Oct 02:23

[PATCH] Fix Linux RAID detection

After upgrading to udev 128, the devices of my RAID array stopped being
detected as such by vol_id.  The reason is that libvolume_id lacks large
file support, so it couldn't seek to the end of my 500GB devices to find
the RAID magic.  This patch simply #includes config.h in util.c so that
the proper macros are defined, bringing in a 64-bit lseek().  If any
other backends apart from Linux RAID require a volume_id_get_buffer()
that has 64-bit support, they will obviously be fixed by this as well.

diff -ru udev-128/extras/volume_id/lib/util.c udev-128.new/extras/volume_id/lib/util.c
--- udev-128/extras/volume_id/lib/util.c	2008-09-09 17:37:38.000000000 -0700
+++ udev-128.new/extras/volume_id/lib/util.c	2008-09-30 15:55:19.402775372 -0700
@@ -21,6 +21,7 @@
 #define _GNU_SOURCE 1
 #endif

+#include <config.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thomas Drillich | 1 Oct 00:58

ide dvd burner detected as ide-tape

Hi,

I found in the syslog:
Sep 30 13:44:44 localhost kernel: ide-tape: hda <-> ht0: HH- <at> T)SPȴ/�����1*00 
DRD)RAM GH22LP20P�{�����л�����HH- <at> T)SPȴ/�����1*00 rev 1*00
Sep 30 13:44:44 localhost kernel: ide-tape: ht0: I/O error, pc = 1a, key =  5, 
asc = 64, ascq =  0
Sep 30 13:44:44 localhost kernel: ide-tape: hda: invalid tape speed (assuming 
650KB/sec)
Sep 30 13:44:44 localhost kernel: ide-tape: hda: invalid max_speed (assuming 
650KB/sec)
Sep 30 13:44:44 localhost kernel: ide-tape: ht0: I/O error, pc = 1a, key =  5, 
asc = 64, ascq =  0
Sep 30 13:47:17 localhost kernel: ide-tape: hda <-> ht0: HH- <at> T)SPȴ/�����1*00 
DRD)RAM GH22LP20P�{�����������HH- <at> T)SPȴ/�����1*00 rev 1*00
Sep 30 13:47:17 localhost kernel: ide-tape: ht0: I/O error, pc = 1a, key =  5, 
asc = 64, ascq =  0
Sep 30 13:47:17 localhost kernel: ide-tape: hda: invalid tape speed (assuming 
650KB/sec)
Sep 30 13:47:17 localhost kernel: ide-tape: hda: invalid max_speed (assuming 
650KB/sec)
Sep 30 13:47:17 localhost kernel: ide-tape: ht0: I/O error, pc = 1a, key =  5, 
asc = 64, ascq =  0
-- end snip

but its a LG GH22LP20 DVD burner

cat /sys/bus/ide/devices/0.0/model returns
	HL)DP-ST <at> V@-RAI CH22HP20

(Continue reading)

Alan Jenkins | 29 Sep 18:49

Debug build fails

udevadm-info.c: In function ‘print_all_attributes’:
udevadm-info.c:65: error: ‘udev’ undeclared (first use in this function)
udevadm-info.c:65: error: (Each undeclared identifier is reported only once
udevadm-info.c:65: error: for each function it appears in.)
udevadm-info.c:72: error: ‘info’ undeclared (first use in this function)

The dbg() macro sucks.  The disabled version should be an inline
function, so it catches these errors on normal builds. 

Obviously the callers need to be fixed before this can be applied.

------------>

Allow compiler to check dbg() arguments on non-debug builds

Signed-off-by: Alan Jenkins <alan-jenkins <at> tuffmail.co.uk>

diff --git a/udev/lib/libudev-private.h b/udev/lib/libudev-private.h
index 162b33a..8f84715 100644
--- a/udev/lib/libudev-private.h
+++ b/udev/lib/libudev-private.h
@@ -23,12 +23,17 @@
 #include <syslog.h>
 #include "libudev.h"

+static inline void __attribute__ ((format(printf, 2, 3)))
+log_null(struct udev *udev, const char *format, ...)
+{
+}
+
(Continue reading)

Alan Jenkins | 29 Sep 18:36

[PATCH] Fix messages (inc. debug compile failure) introduced when optimizing "goto"

My bad.

Signed-off-by: <alan-jenkins <at> tuffmail.co.uk>

diff --git a/udev/udev_rules_parse.c b/udev/udev_rules_parse.c
index 81ba51f..b7ae06a 100644
--- a/udev/udev_rules_parse.c
+++ b/udev/udev_rules_parse.c
@@ -63,7 +63,7 @@ struct udev_rule *udev_rules_iter_goto(struct udev_rules_iter *iter, size_t rule
 	struct udev_rules *rules = iter->rules;
 	struct udev_rule *rule;

-	dbg(rules->udev "current=%zi\n", iter->current);
+	dbg(rules->udev, "current=%zi\n", iter->current);
 	iter->current = rule_off;
 	rule = (struct udev_rule *) (rules->buf + iter->current);

@@ -745,10 +745,10 @@ static int parse_file(struct udev_rules *rules, const char *filename)
 		if (rule->goto_label.operation != KEY_OP_UNSET) {
 			char *goto_label = &rule->buf[rule->goto_label.val_off];

-			dbg(rules->udev, "resolving goto label '%s'", goto_label);
+			dbg(rules->udev, "resolving goto label '%s'\n", goto_label);
 			rule->goto_rule_off = find_label(&iter, goto_label);
 			if (rule->goto_rule_off == iter.current) {
-				err(rules->udev, "goto nonexistent label '%s' in '%s'",
+				err(rules->udev, "goto nonexistent label '%s' in '%s'\n",
 				    goto_label, filename);
 			}
 		}
(Continue reading)

Alan Jenkins | 29 Sep 16:58

[PATCH] replace strerror() usage with threadsafe "%m" format string

strerror() is not threadsafe.  It uses a buffer to build messages of the form
"Unknown error 387689".

syslog() provides a %m format which is equivalent to strerror(errno).
As a GNU extension, this is also accepted by printf and friends.
At least in the current implementation, it is correctly threadsafe.

Signed-off-by: Alan Jenkins <alan-jenkins <at> tuffmail.co.uk>

diff --git a/udev/lib/libudev-ctrl.c b/udev/lib/libudev-ctrl.c
index 7d37074..268ce2d 100644
--- a/udev/lib/libudev-ctrl.c
+++ b/udev/lib/libudev-ctrl.c
@@ -79,7 +79,7 @@ struct udev_ctrl *udev_ctrl_new_from_socket(struct udev *udev, const char *socke

 	uctrl->sock = socket(AF_LOCAL, SOCK_DGRAM, 0);
 	if (uctrl->sock < 0) {
-		err(udev, "error getting socket: %s\n", strerror(errno));
+		err(udev, "error getting socket: %m\n");
 		udev_ctrl_unref(uctrl);
 		return NULL;
 	}
@@ -101,7 +101,7 @@ int udev_ctrl_enable_receiving(struct udev_ctrl *uctrl)

 	err= bind(uctrl->sock, (struct sockaddr *)&uctrl->saddr, uctrl->addrlen);
 	if (err < 0) {
-		err(uctrl->udev, "bind failed: %s\n", strerror(errno));
+		err(uctrl->udev, "bind failed: %m\n");
 		return err;
 	}
(Continue reading)


Gmane