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

Kay Sievers kay.sievers at vrfy.org
Fri Mar 19 10:16:15 UTC 2010


On Fri, Mar 19, 2010 at 10:49, Milan Broz <mbroz at redhat.com> wrote:
> On 03/19/2010 10:24 AM, Kay Sievers wrote:
>> On Fri, Mar 19, 2010 at 10:06, Lars Ellenberg <lars.ellenberg at linbit.com> 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




More information about the dm-devel mailing list