Re: RFC: removing hardcoded "modprobe blktap" in xencommons

["Jan Beulich" <JBeulich@suse.com>]

>>> On 12.07.13 at 20:00, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Jul 12, 2013 at 05:12:55PM +0100, Wei Liu wrote:
>> Back before 4.3 release you complaint about the hardcoded modprobe for
>> blktap / blktap2 in xencommons script. I started to look into it this
>> week and tried to do this modprobe automatically in libxl (that's the
>> idea we discussed before 4.3 IIRC).

But you understand that the complaint isn't just about blktap, but
about _all_ of the modprobes there.

>> Unfortunately I didn't manage to find any canonical documents on how a
>> user space process can trigger a modprobe. I've looked at kernel
>> documentations and couldn't find any. Do you have any reference on how
>> to do that?
> 
> Ian and George talked to me on IRC about this. What we found (thanks for
> Greg KH's help) was that you can use 'MODULE_ALIAS("devname:XYZ")'.
> 
> If any user application did an fopen("/dev/XYZ") then said module would be
> automatically loaded.

This works only for drivers for devices with known major:minor, as
otherwise you have a chicken-and-egg problem between udev
needing a way to determine the major:minor pair to create the
/dev node, and the driver wanting to be loaded via udev rules.

Which particularly means that - afaict - drivers (like blktap) using
MISC_DYNAMIC_MINOR aren't suitable for this; I'll be happily
corrected if there nevertheless is a way...

Yet I don't see why this would be needed for backends anyway:
The tool stack knows which backend it needs, and hence can
modprobe its xen-backend:* alias easily enough (i.e. still without
knowing the actual module name).

Jan