Bug#550152: udev - Remove symlinks

2010-04-22 Thread Marco d'Itri
clone 550152 -1
retitle -1 udev rules must not rename kernel devices
reassign -1 dmsetup
thanks

/lib/udev/rules.d/55-dm.rules needs to be fixed:

On Apr 19, Kay Sievers kay.siev...@vrfy.org wrote:

  ENV{DM_NAME}==?*, NAME=mapper/$env{DM_NAME}, SYMLINK+=$kernel
 
 This is not supported and must be fixed. Udev does not support
 swapping primary device names around, and devtmpfs will always create
 the device node with the kernel name anyway.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-19 Thread Kay Sievers
On Sun, Apr 18, 2010 at 23:08, Marco d'Itri m...@linux.it wrote:
 On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de wrote:
  KERNEL==audio,                NAME=%k0,             SYMLINK+=%k
 Nowadays this is considered bad, accordingly to the upstream maintainer
 you should not change the kernel name of a device.

 $ grep -rl 'NAME=[^=]' /etc/udev/rules.d /lib/udev/rules.d
 /etc/udev/rules.d/70-persistent-net.rules

NAME for network devices is fine. They also rename the kernel device.

 /etc/udev/rules.d/00-local.rules

If this specifies a name different than the kernel device name, it is
something that should be fixed.

 /lib/udev/rules.d/75-persistent-net-generator.rules

NAME for network devices is fine, as mentioned.

 /lib/udev/rules.d/55-dm.rules

Device-mapper is work-in-progress, and probably just uses NAME=
which is ok. (should still not be done that way, but it does not
matter here).

 /lib/udev/rules.d/50-udev-default.rules

It's probably just for support of older kernels, or for deprecated
subsystems drivers like ieee1394, which need to be replaced by
firewire. There should be no rule that specifies a name that is
different from the kernel device name.

 Apart from my own rules this seems to be quite a common behaviour.

Swapping plain kernel-defined names with symlinks is not supported. It
may work, but the behavior is undefined. Recent kernels provide *all*
device node names, and with devtmpfs they also manage their creation
and deletion. On recent systems, udev is only expected to manage
additional symlinks and the permissions of the kernel-created device
node.

 Well, I think moving device nodes forth and back in the /dev tree is
 quite common behavior

Upstream udev does not really support this. Kernel device names are
defined (and optionally created and deleted) by the kernel these days.

Thanks,
Kay



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-04-19 Thread Marco d'Itri
On Apr 19, Kay Sievers kay.siev...@vrfy.org wrote:

  /lib/udev/rules.d/55-dm.rules
 Device-mapper is work-in-progress, and probably just uses NAME=
 which is ok.
There is this rule, which is what the original poster was complaining
about:

ENV{DM_NAME}==?*, NAME=mapper/$env{DM_NAME}, SYMLINK+=$kernel

if you do not plan to fix this then I will reassign the bug to dmsetup.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-19 Thread Kay Sievers
On Mon, Apr 19, 2010 at 11:46, Marco d'Itri m...@linux.it wrote:
 On Apr 19, Kay Sievers kay.siev...@vrfy.org wrote:

  /lib/udev/rules.d/55-dm.rules
 Device-mapper is work-in-progress, and probably just uses NAME=
 which is ok.
 There is this rule, which is what the original poster was complaining
 about:

 ENV{DM_NAME}==?*, NAME=mapper/$env{DM_NAME}, SYMLINK+=$kernel

This is not supported and must be fixed. Udev does not support
swapping primary device names around, and devtmpfs will always create
the device node with the kernel name anyway.

If this is the intended behavior, the dm driver in the kernel needs to
provide this name (the kernel would need to properly be able to handle
block device renames though, which it can't. So is it not expected to
be the case anytime soon).

Kay



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-04-19 Thread Bastian Blank
On Mon, Apr 19, 2010 at 11:56:37AM +0200, Kay Sievers wrote:
 This is not supported and must be fixed. Udev does not support
 swapping primary device names around, and devtmpfs will always create
 the device node with the kernel name anyway.

The documentation does not stat this constraint. And udev is not
devtmpfs.

Bastian

-- 
You're dead, Jim.
-- McCoy, Amok Time, stardate 3372.7



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-04-19 Thread Kay Sievers
On Mon, Apr 19, 2010 at 12:13, Bastian Blank wa...@debian.org wrote:
 On Mon, Apr 19, 2010 at 11:56:37AM +0200, Kay Sievers wrote:
 This is not supported and must be fixed. Udev does not support
 swapping primary device names around, and devtmpfs will always create
 the device node with the kernel name anyway.

 The documentation does not stat this constraint.

It's a recent change in behavior. Please add this, if you think it
should be mentioned.

 And udev is not devtmpfs.

I guess, I know a bit about both. :)

And devtmpfs, which is mandatory by most major distros now, changed a
bit of udev's logic. Udev is still expected to work without devtmpfs,
but devtmpfs still defines the supported udev features, and some
future version of udev may even require devtmpfs.

Kay



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-04-19 Thread Mario 'BitKoenig' Holbe
On Mon, Apr 19, 2010 at 11:39:28AM +0200, Kay Sievers wrote:
 On Sun, Apr 18, 2010 at 23:08, Marco d'Itri m...@linux.it wrote:
  On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de wrote:
   KERNEL==audio,                NAME=%k0,             SYMLINK+=%k
  /etc/udev/rules.d/00-local.rules
 
 If this specifies a name different than the kernel device name, it is
 something that should be fixed.

These are my own local rules and yes, these rules specify lots of
rename-rules like the one above.

Call it obsessive (well, this is what I'm calling it sometimes :)) or
whatever you like. I personally don't like the kernel's style to threat
0-devices naming different than subsequent ones and prefer the other way
around. I was free to do this all the time from the beginning of ages
(i.e. static, fs-based /dev) up to udev 141. I always did this at my own
risk and it was never a problem. I don't want to push my opinion about
this to others, and I'm sure there are others with exactly the opposite
opinion. I'd just like to be free again :)

  /lib/udev/rules.d/55-dm.rules
 Device-mapper is work-in-progress, and probably just uses NAME=
 which is ok. (should still not be done that way, but it does not
 matter here).

As Marco already pointed out: NAME=mapper/$env{DM_NAME}

  /lib/udev/rules.d/50-udev-default.rules
 It's probably just for support of older kernels, or for deprecated
 subsystems drivers like ieee1394, which need to be replaced by
 firewire. There should be no rule that specifies a name that is
 different from the kernel device name.

I don't know what you exactly consider different... just a few
examples for you to explain which of those you consider good and which
bad:

SUBSYSTEM==bsg,   NAME=bsg/%k
SUBSYSTEMS==usb, KERNEL==hiddev[0-9]*,  NAME=usb/%k
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device,   
NAME=bus/usb/$env{BUSNUM}/$env{DEVNUM}
KERNEL==capi, NAME=capi20,
KERNEL==capi[0-9]*,   NAME=capi/%n
KERNEL==card[0-9]*,   NAME=dri/%k
KERNEL==hw_random,NAME=hwrng
KERNEL==cdemu[0-9]*,  NAME=cdemu/%n
KERNEL==pktcdvd[0-9]*,NAME=pktcdvd/%n
KERNEL==cpu[0-9]*,NAME=cpu/%n/cpuid

  Apart from my own rules this seems to be quite a common behaviour.
 Swapping plain kernel-defined names with symlinks is not supported. It
 may work, but the behavior is undefined.

Well, this is basically the reason why in my own local rules I generally
provide symlinks from the kernel-defined names to the ones I prefer
(which triggers the bug we were talking about here :)).

  Well, I think moving device nodes forth and back in the /dev tree is
  quite common behavior
 Upstream udev does not really support this. Kernel device names are
 defined (and optionally created and deleted) by the kernel these days.

All right, devfs-style so to say.


regards
   Mario
-- 
The question of whether a computer can think is no more interesting than
the question of whether a submarine can swim.  -- E. W. Dijkstra


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-19 Thread Marco d'Itri
On Apr 19, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de wrote:

 I don't know what you exactly consider different... just a few
 examples for you to explain which of those you consider good and which
 bad:
All these just define the standard kernel name for the benefit of old
kernels which did not pass to udev the right device name.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-19 Thread Kay Sievers
On Mon, Apr 19, 2010 at 13:28, Mario 'BitKoenig' Holbe
mario.ho...@tu-ilmenau.de wrote:
 On Mon, Apr 19, 2010 at 11:39:28AM +0200, Kay Sievers wrote:
 On Sun, Apr 18, 2010 at 23:08, Marco d'Itri m...@linux.it wrote:
  On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de wrote:
   KERNEL==audio,                NAME=%k0,             SYMLINK+=%k
  /etc/udev/rules.d/00-local.rules

 If this specifies a name different than the kernel device name, it is
 something that should be fixed.

 These are my own local rules and yes, these rules specify lots of
 rename-rules like the one above.

 Call it obsessive (well, this is what I'm calling it sometimes :)) or
 whatever you like. I personally don't like the kernel's style to threat
 0-devices naming different than subsequent ones and prefer the other way
 around. I was free to do this all the time from the beginning of ages
 (i.e. static, fs-based /dev) up to udev 141. I always did this at my own
 risk and it was never a problem. I don't want to push my opinion about
 this to others, and I'm sure there are others with exactly the opposite
 opinion. I'd just like to be free again :)

Yeah, I'll check the current behavior, and if this is easy to fix.
It's weird to delete a link we just created in the same moment
ourselves. :)

But it might still cause problems now or in the future to replace the
defined kernel name with a symlink with the same name. Multiple
devices can claim the same name and the actual link that is created
get managed by a priority value. When a device goes away, the link
with the next highest priority is re-created. This all will fail in
interesting ways if links and node names are mixed. So the supported
solution is not to touch the kernel names and let udev manage only
symlinks to the standard kernel-provided name.

 I don't know what you exactly consider different... just a few
 examples for you to explain which of those you consider good and which
 bad:

 SUBSYSTEM==bsg,                               NAME=bsg/%k
 SUBSYSTEMS==usb, KERNEL==hiddev[0-9]*,      NAME=usb/%k
 SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device,   
 NAME=bus/usb/$env{BUSNUM}/$env{DEVNUM}
 KERNEL==capi,                 NAME=capi20,
 KERNEL==capi[0-9]*,           NAME=capi/%n
 KERNEL==card[0-9]*,           NAME=dri/%k
 KERNEL==hw_random,            NAME=hwrng
 KERNEL==cdemu[0-9]*,          NAME=cdemu/%n
 KERNEL==pktcdvd[0-9]*,        NAME=pktcdvd/%n
 KERNEL==cpu[0-9]*,            NAME=cpu/%n/cpuid

They are all gone from the upstream rules, and provided by the kernel
itself. And are only needed for older kernels. There is a
compat.rules file in the udev tree which has collected all these
rules, in case old kernels should run with a new udev:
  
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/gentoo/30-kernel-compat.rules;hb=HEAD


  Apart from my own rules this seems to be quite a common behaviour.
 Swapping plain kernel-defined names with symlinks is not supported. It
 may work, but the behavior is undefined.

 Well, this is basically the reason why in my own local rules I generally
 provide symlinks from the kernel-defined names to the ones I prefer
 (which triggers the bug we were talking about here :)).

  Well, I think moving device nodes forth and back in the /dev tree is
  quite common behavior
 Upstream udev does not really support this. Kernel device names are
 defined (and optionally created and deleted) by the kernel these days.

 All right, devfs-style so to say.

It is a real devfs. With devtmpfs the model for udev has changed a
bit. We passed control over the device nodes, and the names to the
kernel, and udev it is expected to manage only permissions and
additional symlinks now.

Kay



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-04-19 Thread Kay Sievers
Udev should no longer delete the link it has created:
  
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=6252f9e732c827defdac38e2eccab0657492d9c9

Still, replacing the default kernel-named nodes with links with the
same name can result in unexpected behavior and is not supported. It
does not matter if devtmpfs is used or not, today the kernel defines
the device nodes names, and udev manages only additional symlinks and
the node's permissions.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-04-19 Thread Mario 'BitKoenig' Holbe
Hello Kay,

On Mon, Apr 19, 2010 at 07:06:06PM +0200, Kay Sievers wrote:
 Udev should no longer delete the link it has created:
   
 http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=6252f9e732c827defdac38e2eccab0657492d9c9

Thank you very much. The patch works well:

$ ls -l /dev/dm* /dev/audio*
lrwxrwxrwx  1 root root   6 Apr 19 20:43 /dev/audio - audio0
crw-rw+ 1 root audio 14,  4 Apr 19 20:43 /dev/audio0
crw-rw+ 1 root audio 14, 20 Apr 19 20:43 /dev/audio1
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-0 - mapper/md1
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-1 - mapper/md2
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-2 - mapper/md3
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-3 - mapper/md4
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-4 - mapper/md5
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-5 - mapper/md6
lrwxrwxrwx  1 root root  10 Apr 19 20:43 /dev/dm-6 - mapper/md7

 Still, replacing the default kernel-named nodes with links with the
 same name can result in unexpected behavior and is not supported. It
 does not matter if devtmpfs is used or not, today the kernel defines
 the device nodes names, and udev manages only additional symlinks and
 the node's permissions.

Yes, I got that. It would probably be a good idea, as Bastian suggested
in Message-ID: 20100419101316.ga31...@wavehammer.waldi.eu.org, to
document this.

A note in the manpage should be enough, something like ...

|   The following keys can get values assigned:
|
|   NAME
|   The name of the node to be created, or the name the network
|   interface should be renamed to.
NOTE: changing the kernel-provided name of device nodes
(except for network devices) is not supported and can result
in unexpected behavior.
Today, the kernel defines the device nodes names, and udev
is expected to only manage the node's permissions and
additional symlinks.

... should be sufficient (I used most of your sentence, just tried to
re-organize it a little bit to match importance).


Thanks again  best regards
   Mario
-- 
Computer Science is no more about computers than astronomy is about
telescopes.   -- E. W. Dijkstra


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-18 Thread Marco d'Itri
On Mar 15, Marco d'Itri m...@linux.it wrote:

Can you still reproduce this bug with a recent udev a 2.6.32?
   Sure.
  Then please raise the log level to debug in udev.conf, restart udevd and
  trigger an event.
  I need both the log and the udevadm monitor output.
 udevadm monitor --property
Are there any news?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-18 Thread Marco d'Itri
On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de wrote:

 KERNEL==audio,NAME=%k0, SYMLINK+=%k
Nowadays this is considered bad, accordingly to the upstream maintainer
you should not change the kernel name of a device.
I expect that if you swap NAME and SYMLINK it would work again.

I uploaded to http://www.bofh.it/~md/debian/ a *TOTALLY UNTESTED*
package of a current GIT snapshot: there have been some upstream changes
related to this but I am not even sure that this would be accepted as a
bug.

 Btw. from what I have seen in the changelogs, I second Bastians
 assumption about the reason for the missing symlinks.
I think I missed it, what would that be?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-04-18 Thread Mario 'BitKoenig' Holbe
On Sun, Apr 18, 2010 at 08:27:44PM +0200, Marco d'Itri wrote:
 On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de wrote:
  KERNEL==audio,NAME=%k0, SYMLINK+=%k
 Nowadays this is considered bad, accordingly to the upstream maintainer
 you should not change the kernel name of a device.

$ grep -rl 'NAME=[^=]' /etc/udev/rules.d /lib/udev/rules.d
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/00-local.rules
/lib/udev/rules.d/75-persistent-net-generator.rules
/lib/udev/rules.d/55-dm.rules
/lib/udev/rules.d/50-udev-default.rules

Apart from my own rules this seems to be quite a common behaviour.

 I expect that if you swap NAME and SYMLINK it would work again.

Yes, but this is a) not what I want and b) not what this bug is about :)
See below for further arguments regarding a).

 I uploaded to http://www.bofh.it/~md/debian/ a *TOTALLY UNTESTED*
 package of a current GIT snapshot: there have been some upstream changes
 related to this

No change regarding this issue. The symlink is still removed shortly
after being created.

diff udev-146~udev-event.c udev-152~git~udev-event.c
+   /* remove kernel-created node, if needed */
+   if (udev_device_get_knodename(dev) != NULL  
strcmp(event-name, udev_device_get_knodename(dev)) != 0) {
+   struct stat stats;
+   char filename[UTIL_PATH_SIZE];
+
+   util_strscpyl(filename, sizeof(filename), 
udev_get_dev_path(event-udev), /, udev_device_get_knodename(dev), NULL);
+   if (stat(filename, stats) == 0  
stats.st_rdev == udev_device_get_devnum(dev)) {
+   info(event-udev, remove kernel 
created node '%s'\n, udev_device_get_knodename(dev));
+   util_unlink_secure(event-udev, 
filename);
+   util_delete_path(event-udev, filename);
+   }
+   }

Probably, using lstat() instead of stat() here would fix this specific
problem, but I'm not sure if this is (or should be) really the right way
to fix this.

 but I am not even sure that this would be accepted as a
 bug.

Well, I think moving device nodes forth and back in the /dev tree is
quite common behaviour - let it be users or applications who like to
group device nodes in subdirectories (devfs-style, for example), let it
be device-mapper (lvm, dmsetup, cryptsetup) who likes to rename device
nodes to more verbose names, let it be network devices which fortunately
or unfortunately have no device-node representation (yet), let it be
something else.

Replacing the original device node with a symlink is then just a usual
consequence because some applications appear to depend on specific names
(whether this makes sense or not).

  Btw. from what I have seen in the changelogs, I second Bastians
  assumption about the reason for the missing symlinks.
 I think I missed it, what would that be?

H, sorry my fault. I somehow remember about an assumption that the
removed symlinks had to do with some reorganized/simplified node
handling. I thought Bastian did assume this originally but this doesn't
seem to be the case.


regards
   Mario
-- 
Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft
alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den
Unsinn und den Stumpfsinn.
 [Holger Veit in doc]


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-03-14 Thread Marco d'Itri
On Feb 28, Marco d'Itri m...@linux.it wrote:

   Can you still reproduce this bug with a recent udev a 2.6.32?
  Sure.
 Then please raise the log level to debug in udev.conf, restart udevd and
 trigger an event.
 I need both the log and the udevadm monitor output.
udevadm monitor --property

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-02-28 Thread Marco d'Itri
Can you still reproduce this bug with a recent udev a 2.6.32?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2010-02-28 Thread Bastian Blank
On Sun, Feb 28, 2010 at 03:02:32PM +0100, Marco d'Itri wrote:
 Can you still reproduce this bug with a recent udev a 2.6.32?

Sure.

Bastian

-- 
Bones: The man's DEAD, Jim!



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#550152: udev - Remove symlinks

2010-02-28 Thread Marco d'Itri
On Feb 28, Bastian Blank wa...@debian.org wrote:

  Can you still reproduce this bug with a recent udev a 2.6.32?
 Sure.
Then please raise the log level to debug in udev.conf, restart udevd and
trigger an event.
I need both the log and the udevadm monitor output.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#550152: udev - Remove symlinks

2009-10-07 Thread Bastian Blank
Package: udev
Version: 146-4
Severity: important

udev removes symlinks it created before.

| Oct  7 23:47:00 devel udevd-work[16719]: creating symlink '/dev/dm-0' to 
'mapper/vg0_devel-swap'
| Oct  7 23:47:00 devel udevd-work[16719]: removed kernel created node 
'/dev/dm-0'

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, Who Mourns for Adonais? stardate 3468.1



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org