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

[Peter Rajnoha]

On 03/19/2010 03:08 PM, Hannes Reinecke wrote:
> As mentioned earlier, CHANGE events do not carry any
> information about _what_ has changed.
> The udev rules / programs are expected to check for
> this themselves. So from that point of view yes, you
> cannot simply wait for 'the' CHANGE event as you
> might get more than one.
> 
> I guess most of this discussion could be solved if
> the CHANGE events would be modify to attach some
> enviroment variables indicating the nature of the change.
> 
> EG adding 'DM_STATE=LIVE' or whatever is appropriate
> here.

As for the variables, we already carry some important
information within uevents.

Generally, it carries hints for udev rules to instruct them
how they should be applied correctly, which parts should be
run based on the type of the device, it's real meaning with all
relations to other devices taken into account within that
DM subsystem used (e.g. LVM2's snapshots, mirrors...).

Most of this information is really not suitable to be stored
as a sysfs attribute since it deals with userspace notions,
an abstraction layer above device-mapper...

So the CHANGE event should carry all this information to
properly do all necessary actions and decisions while processing
the udev rules. This information is not easy to acquire by just
calling some program in userspace (from udev rules as most of
the others do). The device can be in the middle of processing
and that event could be just a part of the whole sequence
(also, it's not only that one device, we deal with all sorts
of relations among devices).

Now, the problem we're hitting are those artificial events
generated as a result of the "watch" rule and "udevadm trigger"
that could be triggered anytime. These are just plain events
that we can't even ignore. We have to apply all the rules for
them, but since we don't have the hints/flags, they are applied
incorrectly (creating nodes/symlinks where it is not appropriate,
calling programs from udev rules that are not appropriate etc.).

The proposal here was to keep such information in udev db
so it's still accessible while processing any of the "artificial"
events.

We can and already do provide some information in uevent's
environment, but the idea is broken by those spurious events.
As mentioned already, we made a proposal to make these bits of
information accessible even for the other events...

And the final solution needs cooperation from both sides.

Peter