Re: [Xen-devel] [PATCH v2 4/6] raisin: pass --with-system-seabios with seabios was built

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel