On 03/19/2010 12:44 PM, Kay Sievers wrote: > On Fri, Mar 19, 2010 at 12:14, Milan Broz <mbroz@xxxxxxxxxx> wrote: >> On 03/19/2010 11:16 AM, Kay Sievers wrote: >> Well. And what should happen if anyone generate >> artificial CHANGE event before the real first CHANGE event comes from >> subsystem? (yes, I am looking at you, OPTIONS+="watch" thing for example) > > We retrieve the device state and if it's not ready, we just exit. How? By scanning/opening it? Scan on uninitialised device can lock the device and break initialisation, "-EBUSY" - isn't it race? So all applications, which run some kind of configuration of device should expect that device can be randomly locked by udev rules... [Yes, it happens. I solved several problems in cryptsetup where various udev scans open and locks keyslot device. (Ignoring the fact that it contains key material, in this case it was not security problem - the material is still obfuscated.) These are now masked in udev rules, but I do not like this approach much.] > Yeah, usually it does not create any meta-information besides the > primary device node. Unfortunately it is not the DM/LVM etc case - we had always symlinks and long device names etc. Anyway, this name/uuid information is in sysfs now. But not the VG/LV symlinks info which is pure userspace abstraction... Milan -- mbroz@xxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
