From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: RFC: removing hardcoded "modprobe blktap" in
	xencommons
Date: Mon, 15 Jul 2013 08:44:53 +0100
Message-ID: <51E3C49502000078000E4D3D@nat28.tlf.novell.com>
References: <20130712161255.GB4409@zion.uk.xensource.com>
	<51E3AD9C02000078000E4C9D@nat28.tlf.novell.com>
	<20130715073309.GA25286@zion.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>
In-Reply-To: <20130715073309.GA25286@zion.uk.xensource.com>
Content-Disposition: inline
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: Wei Liu <wei.liu2@citrix.com>
Cc: GeorgeDunlap <george.dunlap@eu.citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

>>> On 15.07.13 at 09:33, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, Jul 15, 2013 at 07:06:52AM +0100, Jan Beulich wrote:
>> >>> On 12.07.13 at 18:12, Wei Liu <wei.liu2@citrix.com> 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).
>> > 
>> > 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?
>> 
>> Not sure what you're asking about. system("modprobe <modname>")
>> is what I'd start with, or utilizing any process spawning internal
>> interface libxl already has.
>> 
> 
> I'm asking because:
> 
> 1) removing that specific one-liner requires giantic amount of work --
>    around 200 lines of code plumbing into libxl's AO interface

There's going to be changes, yes, but as said these should benefit
all backends requiring kernel modules, not just blktap. Hence the
payoff will be bigger.

> 2) not all libxl consumers has the necessary privilege to run modprobe
>    AIUI.

A tool stack controlling kernel based backends necessarily has to
have a way to load kernel modules.

>> > And, why do you think it is bad to have "modprobe blktap" in xencommons?
>> > What about not removing it?
>> 
>> I think the discussion why this is a bad idea was long settled: It is
>> bad practice to load all sorts of stuff regardless of whether it's
>> actually used - not only from a resource usage pov, but also from
>> a security one (less kernel code running implies less kernel bugs to
>> worry about allowing an eventual exploit).
>> 
> 
> Agreed. This issue should be ideally fixed for all drivers using the
> loading methanism mentioned by Konrad. However blktap is unmaintained I
> don't know how feasible it is to modify its source code and push this
> change to ancient kernels.

I don't see what modifications you want/need to make.

Jan