From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.4 development update Date: Mon, 19 Aug 2013 12:38:16 +0100 Message-ID: <521203A8.8000300@eu.citrix.com> References: <20130815130227.GB7042@zion.uk.xensource.com> <520CEED102000078000EC339@nat28.tlf.novell.com> <20130815132428.GD7042@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130815132428.GD7042@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Jackson , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 15/08/13 14:24, Wei Liu wrote: > On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote: >>>>> On 15.08.13 at 15:02, Wei Liu wrote: >>> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>>> * Remove hardcoded mobprobe's in xencommons >>>> owner: Wei Liu >>>> status: still in discussion >>>> >>> Have we not reached conclusion here? IIRC in a engineering meeting we >>> had you said we could just leave it as-is for now? >> ??? Didn't we long ago agree that this hard coded loading is bogus >> and hence should go away? Remember this was originally planned >> to happen for 4.3, so any change in direction here needs a very >> good reason imo. >> > Actually I wasn't completely sure I remembered the right thing. I might > be wrong about the conclusion. Geroge, do you have any clue? :-) I think the conclusion we came to was as follows: * Calling modprobe from libxl is not really feasible due to the fact that we have to call exec, which means making some of the calls async; one thing led to another and a huge number of calls would have had to be made async. * It is better if kernels use the auto-load mechanisms as much as possible, rather than modprobes either in the init scripts or from libxl * However, blktap is unmaintained. Unless someone steps up to add the functionality (which is not recommended as it would probably te a waste of effort), it will continue to require a modprobe. On newer systems, without blktap, the modprobe will be harmless. So for blktap, the modprobe will have to remain for the forseeable future. * It would be good if other modules were modified so that they were auto-loaded, rather than modprobed. However, this was outside of the scope of the work I or Wei agreed to do. We agreed to handle blktap, and the blktap module loading issue has been resolved. * Modifying other modules is an open ticket item Correct me if I'm wrong, anyone. I can put "auto-load other modules" on the roadmap without an owner, if you like. -George