From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wei Liu <wei.liu2@citrix.com>
Subject: Re: RFC: removing hardcoded "modprobe blktap" in
	xencommons
Date: Thu, 1 Aug 2013 14:27:04 +0100
Message-ID: <20130801132703.GB3585@zion.uk.xensource.com>
References: <20130715073309.GA25286@zion.uk.xensource.com>
	<51E3C49502000078000E4D3D@nat28.tlf.novell.com>
	<20130715082656.GC25286@zion.uk.xensource.com>
	<51E3DE2A02000078000E4DCC@nat28.tlf.novell.com>
	<20130715093845.GA28802@zion.uk.xensource.com>
	<51E40240.5010108@eu.citrix.com>
	<20966.31985.748264.709101@mariner.uk.xensource.com>
	<20130718073127.GA26530@zion.uk.xensource.com>
	<51E7AAA5.7090803@eu.citrix.com>
	<20967.52656.555850.362624@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <20967.52656.555850.362624@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

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.