Peter Rajnoha | 19 Oct 13:46 2009
Picon

[PATCH 3/4] Edit udev rules to use new udev flags and a cleanup

Changes in udev rules:

10-dm.rules
  - we need to decode the flags first, so we call "dmsetup udevflags"
  - I've removed OPTIONS+="last_rule" based for inappropriate devices
    that should not be processed further (like temporary-cryptsetup).

    Also, I've added ENV{DM_UUID}=="mpath-?*", ENV{DM_ACTION}=="PATH_FAILED", GOTO="dm_disable",
    this one is issued on PATH_FAIL and we definitely don't want to process this (...and
    call blkid on this one, as an example). I use the flags instead of OPTIONS+="last_rule".

    There is a potential danger here and that is when someone does not check the flags
    to filter out these events (in contrast to OPTIONS+="last_rule"). However, the use
    of OPTIONS+="last_rule" is controversial and a source of potential disputes.
    I'm still not convinced about withdrawing the last_rule, I'll probably ask someone
    from udev directly to get the opinion...

11-lvm.rules:
  - since we have DM_UDEV_RULES_VSN that is defined only when 10-dm.rules is processed,
    we don't need to do a filter on SUBSYSTEM and KERNEL again. Also, we don't need
    to check again the situation with the coldplug.

12-dm-disk.rules:
  - the same as with 11-lvm.rules...
  - we set higher priority for the symlink with the possibility of the same name
    (/dev/disk/by-uuid that is based on FS UUID).
  - (it does not work now because of the bug in udevd/libudev - patch is on a way
     to udev team :) )

12-dm-permissions.rules:
(Continue reading)

Peter Rajnoha | 21 Oct 10:29 2009
Picon

Re: [PATCH 3/4] Edit udev rules to use new udev flags and a cleanup

On 10/19/2009 01:46 PM, Peter Rajnoha wrote:
>     However, the use
>     of OPTIONS+="last_rule" is controversial and a source of potential disputes.
>     I'm still not convinced about withdrawing the last_rule, I'll probably ask someone
>     from udev directly to get the opinion...

Just for the record, the statement I got from Kay Sievers from udev about this is that
we shouldn't use the "last_rule" at all because it could create an "inconsistent behavior"
and it should be removed.

The truth is that with "last_rule" some of the problems could stay hidden forever, because
only when something really breaks, people will react promptly :) So if we're going to play
udev rules, others should play device-mapper rules as well and do not try to process dm
devices when they are instructed to do so by means of checking certain environment variables
we set for them.

(Basically, there are two options - either we check the state and use last_rule and other
rules won't be processed or we rely on others checking these flags/env vars.)

Any comments are welcome..

Peter

--
lvm-devel mailing list
lvm-devel <at> redhat.com
https://www.redhat.com/mailman/listinfo/lvm-devel


Gmane