On 10/20/2009 03:05 PM, Thomas Bächler wrote: > Peter Rajnoha schrieb: >> 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). > > Okay - which program would do that? > Actually, I can't think of anyone listening to the events this way right now... If there's anybody, they really need to have a reason to do that. >> 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. > > Does it matter? If I remember correctly, libdevmapper creates the > /dev/mapper/* nodes itself even if udev isn't there. So cryptsetup would > create the temporary-cryptsetup-* node, access it and destroy it and > udev would ignore everything else - sounds like a good solution to me. Yes, it does create the nodes itself if udev fails to do so. But I don't think this would be a clean solution. Either we create the nodes by udev or by libdevmapper itself (when the rules are not installed). The thing we kept the node/symlink creation code in libdevmapper even with udev support turned on - that's just a fallback action. And it would always give you a warning message like "<node> not set up by udev. Falling back to direct node creation.". So I wouldn't go this way... > > I will deploy the rule mentioned in earlier posts as a workaroud for now > and then see what is happening upstream - once the upstream rules are in > a good state, I am more than willing to use those rather than > distro-specific ones. > Yes, sure. We have to do this until we have all the changes propagated. Peter _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
