Hey Kay,
On Fri, Mar 19, 2010 at 14:24, Peter Rajnoha <prajnoha@xxxxxxxxxx> wrote:Sure, but as mentioned earlier, these events are just expected to
> On 03/19/2010 10:24 AM, Kay Sievers wrote:
>> No, that's what "change" is for, and we already have these "change"
>> events for dm. Udev does not care if the device is ready or not, it
>> synchronizes /sys and /dev, and that works just fine with "change"
>> events.
>
> CHANGE events, not quite... We can't even rely on these.
>
> Just to mention, there's also a CHANGE event generated when
> read-only flag is set for a device (this is not managed by
> device-mapper of course). This one is generated even before
> the actual CHANGE event that is generated when DM device is
> ready to be used.
fail, and update the current udev state, if they can't retrieve the
needed information or find out that the device in not usable.
I think the problem is the that fact that 3rd party user space
opens the device before it is ready (e.g. just after ADD but before
the first CHANGE) makes things fall over.
This short-coming is what needs to get fixed, I think - it's very
fragile this way and since any random user / package can add
rules to open the device on add events, said user / package can
make device-mapper fail. Which doesn't exactly strike me
as robust behavior.
While Alasdair may believe this is "silly" or because someone
is "confused", this can and will happen because our current
user-base love to fiddle around with udev rules to the extent
that various 3rd party packages will ship a lot of them.
David
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
