Re: [Xen-devel] RFC: removing hardcoded "modprobe blktap" in xencommons

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: RFC: removing hardcoded "modprobe blktap" in 
xencommons"):
> It can defer modules *for systems that can load them automatically*, 
> while loading them immediately for those that don't.  I think that's an 
> improvement.

I think we are getting into trouble here because we are lumping
together all of these modprobes.

Wei is talking specifically about "modprobe blktap" (or indeed
"modprobe blktap2").  Modern kernels don't have this module at all, so
there is little harm in trying to load it.

Jan is talking about various other modules.  I agree with Jan that we
should, for example, make sure that ordinary backend drivers (of which
blktap is not one) are loaded using the automatic machinery rather
than explicitly in xencommons.

If there are old kernels whose automatic machinery is broken then
I think testing uname is probably an OK way to support them.  That
avoids having to try to get a bunch of backported module loading fixes
into numerous distros' stable kernels, etc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel