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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Jul 18, 2013 at 12:12:48PM +0100, Ian Jackson wrote:
> 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.
> 

Indeed.

> 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.
> 

Yes, we seemed to mix these two things up.

> 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.
> 

Agreed. However for the blktap case, as you stated above there is
actually no harm doing that modprobe unconditionally.

So by far the proper fix would be:
a) fix all maintained modules to use kernel machinary
b) make use of kernel auto-load machinary in libxl
c) add uname test around module loading in xencommons

Is this correct?


Wei.

> Ian.

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