From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony PERARD Subject: Re: [RFC 4/6] libxl: Add "stubdomain_version" to domain_build_info. Date: Mon, 22 Apr 2013 14:31:06 +0100 Message-ID: <51753B9A.5070503@citrix.com> References: <1366225770-1705-1-git-send-email-anthony.perard@citrix.com> <1366225770-1705-5-git-send-email-anthony.perard@citrix.com> <1366363786.19111.76.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1366363786.19111.76.camel@zakaz.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: Ian Campbell Cc: Xen Devel List-Id: xen-devel@lists.xenproject.org On 19/04/13 10:29, Ian Campbell wrote: > On Wed, 2013-04-17 at 20:09 +0100, Anthony PERARD wrote: >> This enum give the ability to select between the MiniOS based stubdomain >> and the Linux based stubdomain. It can be written in a VM config file via >> "stubdomain_version" variable, but will be automatically filled by the >> appropriate value depending on the device_model_version. To use the >> stubdomain, it's the same config option >> "devive_model_stubdomain_override=1" to force the stubdomain. > > Given that there is no actual choice available (it's minios for > qemu-xen-trad and Linux for qemu-xen) at the moment perhaps we should > just leave this option out for now and cross this bridge if/when there > is a real choice to be made? I feel like this will be an easier thing to do for now. > If we do want to keep this then I think I'd prefer to see us extend the > semantics of device_model_stubdomain_override to be more than a simple > boolean, e.g. make it a libxl enum libxl_device_model_stubdomain_type: > 0 = "none" => process dm in dom0 > 1 = "minios" => mini-os based stubdom > 2 = "linux" => ... > 3 = "foobsd" => ... With this, I don't see how to say: "I want a stubdom for this domain." without having to know which type will be the best (or only) choice. So I go for the no choice for the user, beside stubdom or not. -- Anthony PERARD