From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2 4/6] raisin: pass --with-system-seabios with seabios was built Date: Wed, 22 Apr 2015 15:27:09 +0100 Message-ID: <5537AFBD.4030706@eu.citrix.com> References: <1429634897-14377-4-git-send-email-stefano.stabellini@eu.citrix.com> <1429695758.6604.5.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , Ian Campbell Cc: xen-devel@lists.xensource.com, george.dunlap@citrix.com List-Id: xen-devel@lists.xenproject.org On 04/22/2015 03:15 PM, Stefano Stabellini wrote: > On Wed, 22 Apr 2015, Ian Campbell wrote: >> On Tue, 2015-04-21 at 17:48 +0100, Stefano Stabellini wrote: >>> Detect whether we have built seabios and only pass the relative command >>> line argument to Xen if we actually did. >> >> For this and the following ovmf if we didn't build seabios/ovmf here >> then you pass nothing, which will result in xen.git downloading and >> doing things itself, is that what is wanted? I think, although I confess >> I'm not sure and I haven't checked, you can pass --without-thing to >> avoid this and to disable the support (which might hopefully result in >> clearer error messages to the user down the line). > > This is a good point. I don't know what we want exactly here. > > In the case of OVMF if you don't specify anything the default in Xen is > not to build it. > In the case of Seabios if you don't specify anything the default is > clone and build. > > Do we want to be absolutely sure to avoid any cloning from the > xen-unstable tree with raisin? > Or do we simply want to fall back to the default behaviour? > > I think that both a reasonable answers, I am leaning toward avoiding any > cloning always. This also means disabling stubdoms. What do you think? Well I think what people will expect is that if they disable seabios from ENABLED_COMPONENTS, that it won't be enabled, not that it will still be built but by Xen instead. I think it's reasonable to expect users to do some clean-up if they change their mind about what they want to build. (I wonder if we could use a "./raise distclean", which will rm -rf dist, as well as all components in series but not in COMPONENTS.) Re stubdoms, I think that we should let the xen component do it until it's possible to do it out of tree (i.e., no regression in functionality). -George