From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH 4/9] raisin: add a component to build qemu_traditional Date: Thu, 16 Apr 2015 11:25:35 +0100 Message-ID: References: <1429110900-8286-4-git-send-email-stefano.stabellini@eu.citrix.com> <552E832A.9020900@citrix.com> <552E8870.6020302@citrix.com> <1429113529.15516.344.camel@citrix.com> <21806.36527.622876.472825@mariner.uk.xensource.com> <1429115186.25195.9.camel@citrix.com> <1429173926.25195.30.camel@citrix.com> <1429179039.25195.60.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1429179039.25195.60.camel@citrix.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: george.dunlap@eu.citrix.com, Andrew Cooper , xen-devel@lists.xensource.com, Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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 :-)