Re: add devname module aliases to allow module on-demand auto-loading

From: Kay Sievers
Date: Fri May 21 2010 - 09:55:46 EST


On Fri, May 21, 2010 at 15:39, Nikanth Karthikesan <knikanth@xxxxxxx> wrote:
> On Friday 21 May 2010 18:41:38 Kay Sievers wrote:
>> On Fri, May 21, 2010 at 13:51, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
>> > On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk@xxxxxxxxxx> wrote:
>> >
>> > There is no harm to make a well-know device node static, it just
>> > solves a lot of problems, and also makes it possible to work off of a
>> > static /dev.
>>
>> To illustrate:
>>
>> On my box without this patch:
>> Â dmsetup version
>> Â Library version: Â 1.02.42 (2010-01-14)
>> Â /proc/misc: No entry for device-mapper found
>> Â Is device-mapper driver missing from kernel?
>> Â Failure to communicate with kernel device-mapper driver.
>>
>> And the same box just with this patch, nothing else changed:
>> Â dmsetup version
>> Â Library version: Â 1.02.42 (2010-01-14)
>> Â Driver version: Â Â4.17.0
>>
>> But its up to you to care if device-mapper just works, or if there is
>> stuff like an init script with modprobe needed to load stuff that
>> might never be needed. :)
>>
>
> If this is needed, the dmsetup itself can do a `modprobe dm` instead of
> printing the message, "Is device-mapper driver missing from kernel?"?

No, it can't. There is a delay until the node appears, unless you use
devtmpfs. This can not be handled reliably by usual non-hotplug-aware
tools.

Also it could be any user of libdevmapper doing this. And running
processes from libraries without the user of the lib knowing all the
problems sub-processes create is not recommended at all.

There is a good reason to let the kernel load the module on-demand,
and not to code all sorts of racy stuff into tools. It's just open(),
nothing else, and it is guaranteed by the kenrel to work, without any
further synchronization.

>> This is surely not about dynamic vs. static, it is about race-free
>> on-demand activation of services and subsystems.
>>
> Loading dm-mod alone is enough for `dmsetup version`. But for other operations
> dm-mod may not be enough, as various other modules like dm-crypt, dm-
> mirror,... would also be required, depending on the dm table, which may or may
> not be installed.

Sure, but that is a detail, that can be solved by kernel-driven
on-demand loading as well.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/