Re: [Xen-devel] [PATCH 4/9] raisin: add a component to build qemu_traditional

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 16 Apr 2015, Ian Campbell wrote:
> On Thu, 2015-04-16 at 10:54 +0100, Stefano Stabellini wrote:
> > On Thu, 16 Apr 2015, Ian Campbell wrote:
> > > On Wed, 2015-04-15 at 18:41 +0100, Stefano Stabellini wrote:
> > > > On Wed, 15 Apr 2015, Ian Campbell wrote:
> > > > > On Wed, 2015-04-15 at 17:15 +0100, Ian Jackson wrote:
> > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 4/9] raisin: add 
> > > > > > a component to build qemu_traditional"):
> > > > > > > On Wed, 15 Apr 2015, Ian Campbell wrote:
> > > > > > > > (I also think osstest support is a prerequisite for saying it 
> > > > > > > > is an
> > > > > > > > officially support XenProject thing, but that's offtopic in this
> > > > > > > > context)
> > > > > > > 
> > > > > > > I spoke with IanJ and he didn't seem too keen on adding raisin 
> > > > > > > support
> > > > > > > to osstest before raisin could build everything out of tree. 
> > > > > > > That's way
> > > > > > > I started tackling qemu and qemu-traditional.
> > > > > 
> > > > > I see, I had imagined we would prefer a more piecemeal process.
> > > > > 
> > > > > > I don't mind a hybrid approach.  What I would like is for each
> > > > > > subproject to _either_ do the existing thing, or be able to ask 
> > > > > > raisin
> > > > > > about it in advance.
> > > > > 
> > > > > Isn't that going to be useful/necessary anyway? e.g. as new (i.e.
> > > > > completely new, not moving from xen.git) stuff is added and desirable 
> > > > > to
> > > > > support.
> > > > 
> > > > The integration process that I envisioned is something like the
> > > > following:
> > > > 
> > > > - Add any missing options to the xen-unstable build system to avoid
> > > > cloning and building sub-components, such as qemu, seabios, etc. Many of
> > > > these configure options are already there, like --with-system-qemu and
> > > > --with-system-ovmf.
> > > > 
> > > > - build all these components separately in raisin
> > > > 
> > > > - introduce raisin in osstest
> > > > 
> > > > - disable by default cloning and building sub-components from 
> > > > xen-unstable
> > > > 
> > > > / time passes /
> > > > 
> > > > - remove options to clone and build sub-components from xen-unstable
> > > 
> > > That makes sense. My final paragraph was asking about the next step,
> > > which is adding a completely new component to raisin and integrating it
> > > with osstest, wouldn't osstest then need some way to query raisin about
> > > what it would clone etc?
> > 
> > Raisin has a config file to specify what to clone from where and what
> > revision it should use:
> > 
> > http://xenbits.xen.org/gitweb/?p=people/sstabellini/raisin.git;a=blob_plain;f=defconfig;hb=HEAD
> 
> But can I _query_ what it is able to build (i.e. the components the
> current version supports) and/or what it would actually build if asked
> (i.e. the revisions of things).

If by query you mean issuing an XML-RPC request, the answer is no :-)

All the components are listed in the config file as URLs and REVISIONs,
they also have a component script each, so a single "ls components" will
tell you which components raisin can build. grep _REVISION config will
tell you which versions are going to be built. Nothing will be
automatically built unless it has a _REVISION entry in the config file.
Commenting out a _REVISION entry is a good way to disable the build of
a component.

Each component is independent and there is no knowledge about versions
of one component (xen 4.5 and earlier) needing one or more versions of
another component (qemu-traditional).  The main idea was that the
versions or tags would be supplied by the user. Maybe there should be?
That would increase the complexity though.

I am starting to agree with George that supporting only 4.6+ would be a
decent place to start :-)

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