On Fri, Mar 19, 2010 at 10:59:12AM -0400, David Zeuthen wrote:
> I'd like to reiterate that it's actually not a problem that the sequence is
> - "add" uevent
> - device is not usable, access to the device fails gracefully
> - "change" uevent
> - device usable, blkid on the device etc. works
> the point really is that you have to accept that there will exist
> user space programs that does things on the device between
> "add" and the initial "change" uevent.
It is a problem if both:
1) something attempts to open the devices in that window
AND 2) we have no mechanism to wait for it to finish
Also note that if it is permitted to run 'udevadm trigger' at
any time that also causes a synchonisation problem here: our
application code doesn't even know there is something conflicting
that it needs to wait for. [Even though we want to ignore ADD,
we may still need to synchronise against it.]
So again, the 'don't issue ADD until device is usable' offers a simple
way of avoiding this class of problems. The 'private device
attribute' we suggested offers another - all would be expected
to respect a 'private' sysfs attribute.
Alasdair
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
