On 10/20/2009 02:13 PM, Thomas Bächler wrote: > Peter Rajnoha schrieb: >> Well, we are in the process of the changeover now. As Milan says, what >> we're trying to do is to centralize the udev support for DM devices. >> There were (are?) bits of the rules touching dm devices all over the >> udev rule sets from other packages. > > Is a public discussion happening somewhere? I'd like to follow it or > even participate, as I will be the one who has to fix up this mess in > the end for Arch. > As for LVM/device-mapper related things, there's an "lvm-devel" mailing list and we can discuss the things there as well... >> These flags could be set directly in libdevmapper for each device >> being processed >> (but that's only for kernels >= 2.6.31, because we use cookie values >> to pass this >> information and they were introduced only in 2.6.31). Or we can set >> these flags >> directly in udev rules (like I'm proposing now on lvm-devel where I >> removed >> last_rule for temporary-cryptsetup and like and set these flags >> directly). > > I don't get how this is better than last_rule, except it is more work > and adds extra complexity. All I want is that temporary devices are > being left alone completely. > Well, it's also used to solve some specific situations where udev rules are not enough, e.g. we need specific lvm devices to be visible for a while and then make it invisible later on. If we used plain udev rules, we would set filter based on names only. But since these devices are not renamed in the process, we need to get this information somehow. Since we use those cookies for udev synchronisation, we reuse them to pass these flags into the udev rules, too... I made it more general, so others can use it to pass any bit information to udev rules (we have 16 flags this way). > Your quote from Kay Sievers also mentions events being sent to > listeners, which can "never be suppressed" - the fact is that we > want/need to suppress them - what you suggest doesn't change that. > If I got him right, I think he meant direct listeners of the "KERNEL" udev events like udevd does. Yes, we can't do much here - if anybody listens to the events this way, he is on his own (if we listen to UDEV udev events, then these ones will have those env vars set, so one can check them). > Anyway, looking at the udev manpage, there seems to be a "ignore_device" > option, is that better than last_rule? Shouldn't it fit our situation > better? Or is it yet another option we shouldn't use? > Yes, ignore_device is another way how to suppress the events somehow. But this one will ignore all the rules irrespective of the sequence when it's called. When I tried this one first, I had a rule that sets the nodes and symlinks in /dev/mapper and just after that I called ignore_device, but it ignored everything. So this one can't be used either. >> But such solution (I mean the one without last_rule) expects that >> everybody else >> will be playing device-mapper rules as well. It means always checking >> these >> flags and skip the rules if it is instructed to do so. This solution >> is much cleaner >> from udev perspective since it does not use that last_rule >> functionality... > > Not only dm-specific rules but all rules everywhere need to be aware of > this. There's also site/user-specific rules which could break and and > and - as I said, extra complexity. > >> I know, the solution with OPTIONS+="last_rule" would be much easier, >> since it >> ignores any rules further, but at least this way we can spot all the >> places where >> dm devices are touched by the rules and we can send a notice to those >> maintainers. >> Otherwise this would be hidden forever. > > Good point - but I still think that telling udev to leave the device > alone completely feels like the right thing to do. > Hmm, it's hard to decide... But yes, it's a point to think of. >>>> What is this remove error caused by, if not by some application being >>>> called from udev blocking access? Note that there are no >>>> temporary-cryptsetup-* volumes left after luksOpen. >>> No idea - but always I debubugged it, it was initiated from udev event >>> through udev rule. >> >> ..hmm, this is bound to the actual ruleset that is used in each >> distro. Each >> one should be cleaned and any help is a welcome, really. Also, if you >> spot any >> strange behaviour related to DM devices and udev, just feel free to CC >> me. >> >> Also, I would be very glad if all the rules in all distros would be in >> sync >> with upstream ones. If we could achieve that, it would be great, so we >> would >> have one base and we don't have to solve various problems over and >> over again. > > We're trying to do that, but I think there are some legacies in our > packages - device-mapper didn't have upstream udev rules in the past, so > we added one to get the /dev/mapper/* devices created. That rule is > still there, and probably nobody checked if upstream included something > themselves. > >> ..this is Arch Linux, right? I'll take a look... > > Indeed. > > Our udev rules are a big mess right now for various reasons I wanted to > address soon. All I can say is that the only dm-specific rule is > (included in the device-mapper package): > > ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", > PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M > -m %m", NAME="mapper/%c", MODE="0600", SYMLINK+="disk/by-name/%c" > > Then, the devicekit package also has some rules specific to dm, which I > didn't look at yet (I guess they are just the upstream devicekit rules, > we tend to not change them when possible). > ..that part should be removed as soon as we have all the things resolved and once we have fully functional udev support in Fedora rawhide. David Zeuthen who is responsible for devicekit said he would do that change then. So I believe that this will propagate to the upstream gradually as well. > The problematic rules are the ones that will just touch any block device > - none of those has an explicit check to include or exclude dm-*. I > think this should only be blkid, but I am not sure. > Yes, indeed, blkid call is the source of most problems... Peter _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
