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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/16/2015 11:25 AM, Stefano Stabellini wrote:
> 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.

Well I thought the main idea actually was that the user just tweaks a
few settings, types "./raise fullauto" and everything Just Works? :-)

In which case, having a RELEASE macro (or RELEASE_DEFAULTS?) you could
set to 4.5, 4.6, or unstable seems like the best interface, and which
you could then override with your own branches if you wanted to, would
be the best interface.

That is, unless we want to have something like "git checkout
release/4.5". :-)

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

I think focusing on getting raise and the various Xen trees the way we
want them ideally is a good start.  We can't make major changes to 4.5,
so there's no real time constraint to adding the functionality into
raisin.  (But we should make sure the interface isn't too difficult to
integrate with.)

 -George


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