[dm-devel] [PATCH 1/3] Send KOBJ_ADD event after dm resume ioctl.

[Kay Sievers]

On Fri, Mar 19, 2010 at 12:14, Milan Broz <mbroz at redhat.com> wrote:
> On 03/19/2010 11:16 AM, Kay Sievers wrote:
>
>> There are several subsystems that depend on updating everything with
>> "change" events when device configurations change. There is nothing
>> inherently wrong with this approach, as long as subsystems send the
>> proper "change" events and don't try to hide anything they have
>> registered.
>
> ok, this is perfectly fine with dm devices, CHANGE announces all
> changes. Just I am not sure if all consumers of events (and separate
> rules authors) know about that, I saw so many problems with
> failing something when wrongly reacting to ADD event...
>
> Also it means that after ADD the by-uuid* and similar symlinks
> cannot be yet trusted - if the UUID is read from device and device
> is not yet ready.

Yes, such links will not be created, or even be removed, if we can
not/or no longer retrieve the needed information from the device.

> 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. We
used to do that by calling dmsetup and checking the state of the
device. If the device is ready we create all the stuff, if not, we
just skip the rules. A later event from the subsystem might do the
same stuff again, udev preserves everything that does not get updated,
and this is usually cheap enough and such events do not happen at a
high frequency.

In the simplest case, which will not really apply here, rules could
just check if the size is not "0", and only go ahead if it found a
device which has readable stuff on it.

Ideally, we just gather the needed information from the subsystem
always in the same way, and react on the event the same way,
regardless if it is the first, the second, or any later event.

> According to above, rules must be written such way that every ADD/CHANGE
> event must expect that device is not ready, so it can create only
> partial info in udev, is it correct?
> (this is of course no problem if the rules are the same for both cases)

Yeah, usually it does not create any meta-information besides the
primary device node.

Kay