Re: [PATCH 1/3] Send KOBJ_ADD event after dm resume ioctl.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 18, 2010 at 14:58, Milan Broz <mbroz@xxxxxxxxxx> wrote:
> Block layer sends ADD uevent when new device is initialised.
>
> But the device-mapper block devices are more complex,
> initialisation consists of allocating underlying device and
> loading mapping table.
>
> Because from the userspace all block devices should behave
> the same, patch defines new flag indicating that ADD event
> should be suppressed in block layer.
>
> If the flag is set, caller then take full responsibility
> for enabling and sending events later when device is ready
> to use.

This will disconnect /sys, /dev and /proc from the flow of events. We
rather like to keep them in sync. Device enumeration will find devices
which have never been announced before. It will also find devices
where "remove" was sent, but the device is still there. I don't think
this disconnect is really acceptable from a driver core perspective
and its consumers. On systems without devtmpfs, there will be no
device node for the dm device while there is already the full sysfs
entry and udev would be idle (settle returns), but the state in /sys
not fully reflected in /dev, which is what we should avoid.

How about doing a two-stage instantiation instead of mangling events
to work around this setup model? Instead of creating the mentioned
event/sys inconsistencies, did you think about not registering the
"dead" blockdev until it is ready to be used as a blockdev? Like you
would allocate the dm instance in the kernel, but only register the
blockdev with the block subsystem when the device is resumed/the table
loaded. That way, only after the device is usable, it would get
registered and appear in /dev, /sys and proc.

Thanks,
Kay

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux