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

Kay Sievers kay.sievers at vrfy.org
Fri Mar 19 09:22:18 UTC 2010


On Fri, Mar 19, 2010 at 10:10, Milan Broz <mbroz at redhat.com> wrote:
> On 03/19/2010 09:27 AM, Kay Sievers wrote:
>> On Thu, Mar 18, 2010 at 22:35, Milan Broz <mbroz at redhat.com> wrote:
>
>> /sys is the direct export of kernel objects, if you create objects,
>> they appear, and they get announced. If you don't want them to be
>> announced at that time, just don't register them at that time.
>
> Well, again, I used something what is already used (not on many places,
> but it is there), just search for dev_set_uevent_suppress().
>
> See

Sure, I see. It's code I added myself.

> /* delay uevents, until we scanned partition table */
> dev_set_uevent_suppress(ddev, 1);
>
> ... (part table scan etc. it reads disk, so there can be
> significant delay if device retries read for example)

Come on. It's the same code path, and it's for proper sysfs timing,
not for some it-can-happen-any-time action triggered from userspace.

> So the comment says that base device is announced after all
> partitions devices are created.

Sure, but that's not in any sense what matches your patch, and
"remove" is still fully handled by the core.

> Well, if it is not acceptable (is this what you want to say?),
> what do you suggest?

Leave it as it is, or fix the driver core _interaction_, not the core itself.

> Not use add_disk()/del_gendisk() in dm core and rewrite it?
> This seems like change a lot of code. And after that someone
> surely will say "why dm implements this differently".

Why would anybody say that. You create the _always_visible_ objects
when they are supposed to be visible, that would be all you do. I'm
not saying you need to do that, but you better don't fake around in
driver core events like your patch tries to do.

> But I think it always need a change in device core code.

Sure, we can do all reasonable changes here, inconsistent /sys and
event state we try to avoid for many good reasons.

Kay




More information about the dm-devel mailing list