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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
