On Mon, Apr 27, 2009 at 18:24, Peter Rajnoha <prajnoha@xxxxxxxxxx> wrote:
> The "DM_COOKIE" value you can see in the rules is just a random numeric
> value we set for every action (ioctl) and return as env var in uevents.
> When we want to group these devices together, we just set the same
> cookie value for every device in a group. We can notify the waiting
> process directly this way. We use this method instead of comparing
> queued/processed udev event numbers (this way we are sure we don't waste
> time waiting for unrelated events).
Sounds fine.
> You can spot the use of the "last_rule", which seems to be controversial.
> The reason is that we require reliability and performance and we'd like
> to have more control over the rules that are applied for DM devices
> as well. Also, we would like to minimize any problems caused by some
> general rules creating wrong nodes or delaying the udev response for DM
> devices in any way (the process that fired the actions is waiting for the
> notification from udev rule!). And this is the part I'd like to
> discuss -- I know the usaage of "last_rule" is not perfect for
> the others, but we really need to satisfy the needs described above.
You should not steal events, unless you are absolutely sure, that
nothing else may be interested, or has to update its idea of the
device, and I don't hink you can be sure of such a thing ever. I
suggest you drop the last rule thing entirely, and If you see anything
that goes wrong, let us know, and we will fix it.
> There could be some system that requires the information about
> our devices, but we can resend the events for these systems if it is
> really necessary (for example the HAL). Simply, we need more control
> over this process.
That can not really work, you can not send out-of-band events to something.
> 12-dm.rules (create plain DM device nodes in /dev/mapper)
> ---------------------------------------------------------
> KERNEL=="device-mapper", NAME="exp_mapper/control"
>
> SUBSYSTEM!="block", GOTO="dm_end"
> KERNEL!="dm-[0-9]*", GOTO="dm_end"
> ACTION!="change|remove", GOTO="dm_end"
>
> ACTION=="change", NAME="mapper/$env{DM_NAME}"
Please do not rename kernel devices, they should match the kernel
names. Only create SYMLINK+= to the kernel names, or change the kernel
to ceate the proper names, which will not work I guess, so please
leave them as they are today.
In general we do not want any unneeded disconnect from kernel names
and /dev names, and dm block devices should stay as /dev/dm-* device
nodes.
> 95-dm-fallback.rules
> --------------------
> SUBSYSTEM!="block", GOTO="dm_end"
> KERNEL!="dm-[0-9]*", GOTO="dm_end"
> ACTION!="change|remove", GOTO="dm_end"
>
> # Just in case there is any unsent notification.
> ENV{DM_COOKIE}=="?*", RUN+="/sbin/dmsetup udevnotify $env{DM_COOKIE}", OPTIONS+="last_rule"
Drop the last_rule stuff and this is not needed. :)
> These rules are supposed to be installed in /etc/udev/rules.d dir:
Pleas don't install "documentation" in /etc. Document what is needed
to set custom permissions, put examples in /usr/share/, but please do
not drop "dead" files in /etc. Packages are not supposed to place
anything in /etc. Ideally users area able to do "rm
/etc/udev/rules.d/*" to start from scratch.
> 11-dm-subsystem.rules
> ---------------------
> SUBSYSTEM!="block", GOTO="dm_end"
> KERNEL!="dm-[0-9]*", GOTO="dm_end"
> ACTION!="change", GOTO="dm_end"
>
> # Every DM subsystem registers its own prefixes here.
> # This is required so the notification is sent at right
> # time and after the subsystem's udev rules are processed.
> # We send the notification from the subsystem's rules then.
> # (if we forget to do so, there is still a fallback rule
> # that will send any residual notifications later)
> ENV{DM_UUID}=="LVM-?*", ENV{DM_SUBSYS}="LVM"
> ENV{DM_UUID}=="mpath-?*", ENV{DM_SUBSYS}="mpath"
Seems, stuff like this does not belong into /etc either.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
