From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Shelton Subject: Re: [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info. Date: Mon, 9 Feb 2015 09:11:28 -0500 Message-ID: References: <1423022775-7132-1-git-send-email-eshelton@pobox.com> <1423022775-7132-5-git-send-email-eshelton@pobox.com> <1423473096.23098.12.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1423473096.23098.12.camel@citrix.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: Ian Campbell Cc: Anthony PERARD , xen-devel@lists.xensource.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, Feb 9, 2015 at 4:11 AM, Ian Campbell wrote: > On Tue, 2015-02-03 at 23:06 -0500, Eric Shelton wrote: >> This enum gives the ability to select between a MiniOS-based QEMU >> traditional stub domain and a Linux-based QEMU upstream stub domain. To >> use the Linux-based stubdomain, the following two lines should be >> included in the appropriate xl.cfg file: >> >> device_model_version="qemu-xen" >> device_model_stubdomain_override=1 >> >> To use the MiniOS-based stubdomain, the following is used instead: >> >> device_model_version="qemu-xen-traditional" >> device_model_stubdomain_override=1 > > This doesn't seem to use this new stubdom_version option and I'm not > really sure what it is for. > > Perhaps you meant this new thing to be a libxl internal Enum, rather > than exposed to the application which is using libxl? I believe Anthony's first patchset made this an explicit option for xl.cfg (e.g., 'stubdom_version="linux"'), and then the second patchset continued to use it internally, with the combination of device_model_stubdomain_override and device_model_version setting its value. I suppose the main benefit of this approach is if we foresee more than one stubdom flavor for QEMU-upstream, but we're nowhere near that. > I'm not sure wy > the user would need to be given the choice -- it should be inherent in > the device-model version and stubdom boolean selection. In effect, that is how it works - as illustrated by the two xl.cfg examples above. Perhaps it is best to just eliminate the internal enum, and have the code just look to device_model_version. It has not been a good sign that both Stephano (at least initially) and you have negatively reacted to how it is currently being done. - Eric