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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 22 Apr 2015, George Dunlap wrote:
> 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.)

OK


> 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).

On the other hands current stubdoms are not even tested in osstest, so
we might as well wait for the next generation to be ready before having
them in raisin.

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