[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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


> Ian.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.