On Fri, Mar 19, 2010 at 10:49, Milan Broz <mbroz@xxxxxxxxxx> wrote: > On 03/19/2010 10:24 AM, Kay Sievers wrote: >> On Fri, Mar 19, 2010 at 10:06, Lars Ellenberg <lars.ellenberg@xxxxxxxxxx> wrote: >>> Would introducing a KOBJ_READY_TO_BE_CONSUMED_BY_UDEV help? >> >> 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. > > Udev (rules) do not not care if the device is ready? > > That's really news for me. So you are basically saying that dm ADD event is ok, > and it is problem of udev rules that they react here on ADD event and run > various scan over not-yet-ready device because it should wait for CHANGE? It will not wait, the tools will just fail to open the device, and udev will only create the basic device node, but not possible metadata-based symlinks or anything like that. That is expected behavior, udev will handle just fine. The needed information will only be readable with the next "change" event, and be fully updated with every "change" event after that. Usually, it does not make much sense to distinguish between "add" and "change" in userspace/udev rules. The called udev rules are the same, and should just check a subsystem-provided property if they should go ahead or ignore the device. Udev itself handles "add" and "change" exactly the same way. The only exception is network device renaming, which only runs on "add". 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. Kay -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
