raisin and minios stubdom

raisin and minios stubdom

[Gémes Géza]

Hi,

Currently the xen build system has optional support for building a 
minios (+needed libraries and tools) based stubdom.

What is your opinion about moving support for building this into raisin 
and once that is stable drop support in the xen build system?

Cheers,

Geza


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

Re: raisin and minios stubdom

[Konrad Rzeszutek Wilk]

On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
> Hi,
> 
> Currently the xen build system has optional support for building a minios
> (+needed libraries and tools) based stubdom.
> 
> What is your opinion about moving support for building this into raisin and
> once that is stable drop support in the xen build system?

Why? I do like doing 'make' and 'make install' and it doing everything
for me.

> 
> Cheers,
> 
> Geza
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: raisin and minios stubdom

[Gémes Géza]

> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>> Hi,
>>
>> Currently the xen build system has optional support for building a minios
>> (+needed libraries and tools) based stubdom.
>>
>> What is your opinion about moving support for building this into raisin and
>> once that is stable drop support in the xen build system?
> Why? I do like doing 'make' and 'make install' and it doing everything
> for me.
>
>> Cheers,
>>
>> Geza
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

Because it means that xen build needs to download and build a lot of 3PP 
components. Raisin is already designed to do so (it already builds 
qemu-xen, qemu-traditional, libvirt and a few others). I think building 
anything besides xen proper would fit its scope better.

Cheers,

Geza


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

Re: raisin and minios stubdom

[Konrad Rzeszutek Wilk]

On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
> 
> > On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
> > > Hi,
> > > 
> > > Currently the xen build system has optional support for building a minios
> > > (+needed libraries and tools) based stubdom.
> > > 
> > > What is your opinion about moving support for building this into raisin and
> > > once that is stable drop support in the xen build system?
> > Why? I do like doing 'make' and 'make install' and it doing everything
> > for me.
> > 
> > > Cheers,
> > > 
> > > Geza
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > https://lists.xen.org/xen-devel
> 
> Because it means that xen build needs to download and build a lot of 3PP
> components. Raisin is already designed to do so (it already builds qemu-xen,

If you do 'make src-tarball' it will do that for you - and you can package
all of that in a tarball.

> qemu-traditional, libvirt and a few others). I think building anything
> besides xen proper would fit its scope better.

OK, but that does not square well with RPM build systems. Those are interested
in building just one component (xen+toolstack+its extra pieces). Using
raisin to build everything is not going to fly.

(Also distros like to seperate componets out - so they build qemu-upstream
seperate - which is used by Xen - and they could also do it for MiniOS
if they were spec files for it and such).

> 
> Cheers,
> 
> Geza
> 

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

Re: raisin and minios stubdom

[Juergen Gross]

On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>>
>>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>>>> Hi,
>>>>
>>>> Currently the xen build system has optional support for building a minios
>>>> (+needed libraries and tools) based stubdom.
>>>>
>>>> What is your opinion about moving support for building this into raisin and
>>>> once that is stable drop support in the xen build system?
>>> Why? I do like doing 'make' and 'make install' and it doing everything
>>> for me.
>>>
>>>> Cheers,
>>>>
>>>> Geza
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> https://lists.xen.org/xen-devel
>>
>> Because it means that xen build needs to download and build a lot of 3PP
>> components. Raisin is already designed to do so (it already builds qemu-xen,
> 
> If you do 'make src-tarball' it will do that for you - and you can package
> all of that in a tarball.
> 
>> qemu-traditional, libvirt and a few others). I think building anything
>> besides xen proper would fit its scope better.
> 
> OK, but that does not square well with RPM build systems. Those are interested
> in building just one component (xen+toolstack+its extra pieces). Using
> raisin to build everything is not going to fly.
> 
> (Also distros like to seperate componets out - so they build qemu-upstream
> seperate - which is used by Xen - and they could also do it for MiniOS
> if they were spec files for it and such).

There are only few stubdoms you can build without the Xen tree. How
would you do so for e.g. xenstore-stubdom needing the Xenstore sources
to be built? Several stubdoms need libxc built for stubdom included.
And you want to have a build error if e.g. a libxc modification is
breaking stubdom build.


Juergen

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

Re: raisin and minios stubdom

[Géza Gémes]

[-- Attachment #1.1: Type: text/plain, Size: 2303 bytes --]

2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@suse.com>):

On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>>
>>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>>>> Hi,
>>>>
>>>> Currently the xen build system has optional support for building a
minios
>>>> (+needed libraries and tools) based stubdom.
>>>>
>>>> What is your opinion about moving support for building this into
raisin and
>>>> once that is stable drop support in the xen build system?
>>> Why? I do like doing 'make' and 'make install' and it doing everything
>>> for me.
>>>
>>>> Cheers,
>>>>
>>>> Geza
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> https://lists.xen.org/xen-devel
>>
>> Because it means that xen build needs to download and build a lot of 3PP
>> components. Raisin is already designed to do so (it already builds
qemu-xen,
>
> If you do 'make src-tarball' it will do that for you - and you can package
> all of that in a tarball.
>
>> qemu-traditional, libvirt and a few others). I think building anything
>> besides xen proper would fit its scope better.
>
> OK, but that does not square well with RPM build systems. Those are
interested
> in building just one component (xen+toolstack+its extra pieces). Using
> raisin to build everything is not going to fly.
>
> (Also distros like to seperate componets out - so they build qemu-upstream
> seperate - which is used by Xen - and they could also do it for MiniOS
> if they were spec files for it and such).

There are only few stubdoms you can build without the Xen tree. How
would you do so for e.g. xenstore-stubdom needing the Xenstore sources
to be built? Several stubdoms need libxc built for stubdom included.
And you want to have a build error if e.g. a libxc modification is
breaking stubdom build.


Juergen

Hi,

Raisin already builds xen too, so it has all the dependencies ready.
Regarding the problem of breaking stubdom build by libxc changes I think
those can be prevented if we introduce osstests for raisin build. Maybe we
should start with that, adding raisin to the osstest framework.
Opinions?

Cheers

Géza

[-- Attachment #1.2: Type: text/html, Size: 3591 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: raisin and minios stubdom

[Gémes Géza]

[-- Attachment #1.1: Type: text/plain, Size: 3095 bytes --]

2017-04-01 08:19 keltezéssel, Géza Gémes írta:
>
>
> 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@suse.com 
> <mailto:jgross@suse.com>>):
>
>     On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
>     > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>     >>
>     >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>     >>>> Hi,
>     >>>>
>     >>>> Currently the xen build system has optional support for
>     building a minios
>     >>>> (+needed libraries and tools) based stubdom.
>     >>>>
>     >>>> What is your opinion about moving support for building this
>     into raisin and
>     >>>> once that is stable drop support in the xen build system?
>     >>> Why? I do like doing 'make' and 'make install' and it doing
>     everything
>     >>> for me.
>     >>>
>     >>>> Cheers,
>     >>>>
>     >>>> Geza
>     >>>>
>     >>>>
>     >>>> _______________________________________________
>     >>>> Xen-devel mailing list
>     >>>> Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>     >>>> https://lists.xen.org/xen-devel <https://lists.xen.org/xen-devel>
>     >>
>     >> Because it means that xen build needs to download and build a
>     lot of 3PP
>     >> components. Raisin is already designed to do so (it already
>     builds qemu-xen,
>     >
>     > If you do 'make src-tarball' it will do that for you - and you
>     can package
>     > all of that in a tarball.
>     >
>     >> qemu-traditional, libvirt and a few others). I think building
>     anything
>     >> besides xen proper would fit its scope better.
>     >
>     > OK, but that does not square well with RPM build systems. Those
>     are interested
>     > in building just one component (xen+toolstack+its extra pieces).
>     Using
>     > raisin to build everything is not going to fly.
>     >
>     > (Also distros like to seperate componets out - so they build
>     qemu-upstream
>     > seperate - which is used by Xen - and they could also do it for
>     MiniOS
>     > if they were spec files for it and such).
>
>     There are only few stubdoms you can build without the Xen tree. How
>     would you do so for e.g. xenstore-stubdom needing the Xenstore sources
>     to be built? Several stubdoms need libxc built for stubdom included.
>     And you want to have a build error if e.g. a libxc modification is
>     breaking stubdom build.
>
>
>     Juergen
>
> Hi,
>
> Raisin already builds xen too, so it has all the dependencies ready. 
> Regarding the problem of breaking stubdom build by libxc changes I 
> think those can be prevented if we introduce osstests for raisin 
> build. Maybe we should start with that, adding raisin to the osstest 
> framework.
> Opinions?
>
> Cheers
>
> Géza

Regarding building distro rpms or debs with raisin that was never the 
scope of it. Raisin intends to be a quick method of building xen + a set 
of tools related to it, primarily for development purposes 
(https://wiki.xenproject.org/wiki/Raisin and 
https://blog.xenproject.org/2015/06/28/project-raisin-raise-xen/)

Cheers,

Géza


[-- Attachment #1.2: Type: text/html, Size: 6186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: raisin and minios stubdom

[Juergen Gross]

On 01/04/17 08:19, Géza Gémes wrote:
> 
> 
> 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@suse.com
> <mailto:jgross@suse.com>>):
> 
>     On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
>     > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>     >>
>     >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>     >>>> Hi,
>     >>>>
>     >>>> Currently the xen build system has optional support for
>     building a minios
>     >>>> (+needed libraries and tools) based stubdom.
>     >>>>
>     >>>> What is your opinion about moving support for building this
>     into raisin and
>     >>>> once that is stable drop support in the xen build system?
>     >>> Why? I do like doing 'make' and 'make install' and it doing
>     everything
>     >>> for me.
>     >>>
>     >>>> Cheers,
>     >>>>
>     >>>> Geza
>     >>>>
>     >>>>
>     >>>> _______________________________________________
>     >>>> Xen-devel mailing list
>     >>>> Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>     >>>> https://lists.xen.org/xen-devel <https://lists.xen.org/xen-devel>
>     >>
>     >> Because it means that xen build needs to download and build a lot
>     of 3PP
>     >> components. Raisin is already designed to do so (it already
>     builds qemu-xen,
>     >
>     > If you do 'make src-tarball' it will do that for you - and you can
>     package
>     > all of that in a tarball.
>     >
>     >> qemu-traditional, libvirt and a few others). I think building
>     anything
>     >> besides xen proper would fit its scope better.
>     >
>     > OK, but that does not square well with RPM build systems. Those
>     are interested
>     > in building just one component (xen+toolstack+its extra pieces). Using
>     > raisin to build everything is not going to fly.
>     >
>     > (Also distros like to seperate componets out - so they build
>     qemu-upstream
>     > seperate - which is used by Xen - and they could also do it for MiniOS
>     > if they were spec files for it and such).
> 
>     There are only few stubdoms you can build without the Xen tree. How
>     would you do so for e.g. xenstore-stubdom needing the Xenstore sources
>     to be built? Several stubdoms need libxc built for stubdom included.
>     And you want to have a build error if e.g. a libxc modification is
>     breaking stubdom build.
> 
> 
>     Juergen
> 
> Hi,
> 
> Raisin already builds xen too, so it has all the dependencies ready.
> Regarding the problem of breaking stubdom build by libxc changes I think
> those can be prevented if we introduce osstests for raisin build. Maybe
> we should start with that, adding raisin to the osstest framework.
> Opinions?

osstest is too late. I want to see a build error _before_ sending a
patch.

So how is raisin working exactly? Is it possible to do incremental
buils or is the build always complete? Can I start builds of only a
subtree? Is it possible to use a private version of some sub-component?

I'm not opposed to use raisin e.g. in osstest. I'm opposed to a change
in the developer workflow requiring to spend either much more time for
testing the build or to add additional steps for it. One-time changes
are fine, changes requiring the developer not to forget an additional
command are not.


Juergen

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

Re: raisin and minios stubdom

[George Dunlap]

On Mon, Mar 27, 2017 at 8:28 PM, Gémes Géza <geza.gemes@gmail.com> wrote:
> Hi,
>
> Currently the xen build system has optional support for building a minios
> (+needed libraries and tools) based stubdom.
>
> What is your opinion about moving support for building this into raisin and
> once that is stable drop support in the xen build system?

This was actually the original purpose of raisin: to allow a framework
for simply building all related components of a Xen system without
requiring *everything* to be built in-tree with make.  The thing that
triggered Stefano to write raisin was the availability of grub-xen
(building grub upstream as a PV target) -- there was resistance to
putting Yet Another Thing in the tree.

But the fact is it hasn't gotten much up-take with developers, and I
think you're the first user to give significant feedback on it.  As
you can see, many people prefer to have everything built under one
umbrella.

Logically it makes sense to *either* do things one way (make
everything under xen.git) or the other way (make only xen and tools
under xen.git, and use a tool like raisin to build everything else).
But as a community we haven't been able to agree on either one, and so
the status quo -- most things built under xen.git but nothing *new* --
continues.

In the meantime, there's no reason not to do both.  A normal "make" in
xen.git will build you a qemu, qemu-traditional, seabios, &c; raisin
disables that and builds everything separately.  The plan was always
to do the same thing for minios; nobodys had time to work on it yet.

Hope that makes sense -- join us on freenode channel #xendevel if you
want to chat more about this. :-)

 -George

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

Re: raisin and minios stubdom

[Wei Liu]

On Mon, Apr 03, 2017 at 12:17:08PM +0100, George Dunlap wrote:
> On Mon, Mar 27, 2017 at 8:28 PM, Gémes Géza <geza.gemes@gmail.com> wrote:
> > Hi,
> >
> > Currently the xen build system has optional support for building a minios
> > (+needed libraries and tools) based stubdom.
> >
> > What is your opinion about moving support for building this into raisin and
> > once that is stable drop support in the xen build system?
> 
> This was actually the original purpose of raisin: to allow a framework
> for simply building all related components of a Xen system without
> requiring *everything* to be built in-tree with make.  The thing that
> triggered Stefano to write raisin was the availability of grub-xen
> (building grub upstream as a PV target) -- there was resistance to
> putting Yet Another Thing in the tree.
> 
> But the fact is it hasn't gotten much up-take with developers, and I
> think you're the first user to give significant feedback on it.  As
> you can see, many people prefer to have everything built under one
> umbrella.
> 
> Logically it makes sense to *either* do things one way (make
> everything under xen.git) or the other way (make only xen and tools
> under xen.git, and use a tool like raisin to build everything else).
> But as a community we haven't been able to agree on either one, and so
> the status quo -- most things built under xen.git but nothing *new* --
> continues.
> 
> In the meantime, there's no reason not to do both.  A normal "make" in
> xen.git will build you a qemu, qemu-traditional, seabios, &c; raisin
> disables that and builds everything separately.  The plan was always
> to do the same thing for minios; nobodys had time to work on it yet.
> 

You would be surprised by the patches I had written in the past year.
;-)

Gémes, please check out

  git://xenbits.xen.org/people/liuw/xen.git wip.split-stubdom-v2
  git://xenbits.xen.org/people/liuw/stubdom.git wip.split-stubdom-v2

They were a bit old, but if you want to start working on that, feel free
to take what you need.

Wei.

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

Re: raisin and minios stubdom

[Gémes Géza]

2017-04-03 14:01 keltezéssel, Wei Liu írta:
> On Mon, Apr 03, 2017 at 12:17:08PM +0100, George Dunlap wrote:
>> On Mon, Mar 27, 2017 at 8:28 PM, Gémes Géza <geza.gemes@gmail.com> wrote:
>>> Hi,
>>>
>>> Currently the xen build system has optional support for building a minios
>>> (+needed libraries and tools) based stubdom.
>>>
>>> What is your opinion about moving support for building this into raisin and
>>> once that is stable drop support in the xen build system?
>> This was actually the original purpose of raisin: to allow a framework
>> for simply building all related components of a Xen system without
>> requiring *everything* to be built in-tree with make.  The thing that
>> triggered Stefano to write raisin was the availability of grub-xen
>> (building grub upstream as a PV target) -- there was resistance to
>> putting Yet Another Thing in the tree.
>>
>> But the fact is it hasn't gotten much up-take with developers, and I
>> think you're the first user to give significant feedback on it.  As
>> you can see, many people prefer to have everything built under one
>> umbrella.
>>
>> Logically it makes sense to *either* do things one way (make
>> everything under xen.git) or the other way (make only xen and tools
>> under xen.git, and use a tool like raisin to build everything else).
>> But as a community we haven't been able to agree on either one, and so
>> the status quo -- most things built under xen.git but nothing *new* --
>> continues.
>>
>> In the meantime, there's no reason not to do both.  A normal "make" in
>> xen.git will build you a qemu, qemu-traditional, seabios, &c; raisin
>> disables that and builds everything separately.  The plan was always
>> to do the same thing for minios; nobodys had time to work on it yet.
>>
> You would be surprised by the patches I had written in the past year.
> ;-)
>
> Gémes, please check out
>
>    git://xenbits.xen.org/people/liuw/xen.git wip.split-stubdom-v2
>    git://xenbits.xen.org/people/liuw/stubdom.git wip.split-stubdom-v2
>
> They were a bit old, but if you want to start working on that, feel free
> to take what you need.
>
> Wei.

Hi Wei,

Thank you! I'll definitely start by looking at those. Sorry for being 
slow in answering, unfortunately I'm quite busy nowadays with my job, 
which is unfortunately not Xen related.

Cheers.

Geza


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

Re: raisin and minios stubdom

[Géza Gémes]

[-- Attachment #1.1: Type: text/plain, Size: 3751 bytes --]

On 01/04/17 08:19, Géza Gémes wrote:
>
>
> 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@suse.com
> <mailto:jgross@suse.com>>):
>
>     On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
>     > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>     >>
>     >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>     >>>> Hi,
>     >>>>
>     >>>> Currently the xen build system has optional support for
>     building a minios
>     >>>> (+needed libraries and tools) based stubdom.
>     >>>>
>     >>>> What is your opinion about moving support for building this
>     into raisin and
>     >>>> once that is stable drop support in the xen build system?
>     >>> Why? I do like doing 'make' and 'make install' and it doing
>     everything
>     >>> for me.
>     >>>
>     >>>> Cheers,
>     >>>>
>     >>>> Geza
>     >>>>
>     >>>>
>     >>>> _______________________________________________
>     >>>> Xen-devel mailing list
>     >>>> Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>     >>>> https://lists.xen.org/xen-devel <https://lists.xen.org/xen-devel>
>     >>
>     >> Because it means that xen build needs to download and build a lot
>     of 3PP
>     >> components. Raisin is already designed to do so (it already
>     builds qemu-xen,
>     >
>     > If you do 'make src-tarball' it will do that for you - and you can
>     package
>     > all of that in a tarball.
>     >
>     >> qemu-traditional, libvirt and a few others). I think building
>     anything
>     >> besides xen proper would fit its scope better.
>     >
>     > OK, but that does not square well with RPM build systems. Those
>     are interested
>     > in building just one component (xen+toolstack+its extra pieces).
Using
>     > raisin to build everything is not going to fly.
>     >
>     > (Also distros like to seperate componets out - so they build
>     qemu-upstream
>     > seperate - which is used by Xen - and they could also do it for
MiniOS
>     > if they were spec files for it and such).
>
>     There are only few stubdoms you can build without the Xen tree. How
>     would you do so for e.g. xenstore-stubdom needing the Xenstore sources
>     to be built? Several stubdoms need libxc built for stubdom included.
>     And you want to have a build error if e.g. a libxc modification is
>     breaking stubdom build.
>
>
>     Juergen
>
> Hi,
>
> Raisin already builds xen too, so it has all the dependencies ready.
> Regarding the problem of breaking stubdom build by libxc changes I think
> those can be prevented if we introduce osstests for raisin build. Maybe
> we should start with that, adding raisin to the osstest framework.
> Opinions?

osstest is too late. I want to see a build error _before_ sending a
patch.

So how is raisin working exactly? Is it possible to do incremental
buils or is the build always complete? Can I start builds of only a
subtree? Is it possible to use a private version of some sub-component?


You can use private versions easily. Regarding the problem of selective
rebuild O think that is missing currently, but given your input it looks
important, so I'll look for ways to enable it.


I'm not opposed to use raisin e.g. in osstest. I'm opposed to a change
in the developer workflow requiring to spend either much more time for
testing the build or to add additional steps for it. One-time changes
are fine, changes requiring the developer not to forget an additional
command are not.


As raisin is able to build xen and a set of related projects it is
practically a matter of running raise build rather than make.



Juergen


Cheers

Géza

[-- Attachment #1.2: Type: text/html, Size: 6147 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: raisin and minios stubdom

[Juergen Gross]

On 07/04/17 20:54, Géza Gémes wrote:
> 
>     On 01/04/17 08:19, Géza Gémes wrote:
>     >
>     >
>     > 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@suse.com
>     <mailto:jgross@suse.com>
>     > <mailto:jgross@suse.com <mailto:jgross@suse.com>>>):
>     >
>     >     On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
>     >     > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>     >     >>
>     >     >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
>     >     >>>> Hi,
>     >     >>>>
>     >     >>>> Currently the xen build system has optional support for
>     >     building a minios
>     >     >>>> (+needed libraries and tools) based stubdom.
>     >     >>>>
>     >     >>>> What is your opinion about moving support for building this
>     >     into raisin and
>     >     >>>> once that is stable drop support in the xen build system?
>     >     >>> Why? I do like doing 'make' and 'make install' and it doing
>     >     everything
>     >     >>> for me.
>     >     >>>
>     >     >>>> Cheers,
>     >     >>>>
>     >     >>>> Geza
>     >     >>>>
>     >     >>>>
>     >     >>>> _______________________________________________
>     >     >>>> Xen-devel mailing list
>     >     >>>> Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>     <mailto:Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>>
>     >     >>>> https://lists.xen.org/xen-devel
>     <https://lists.xen.org/xen-devel> <https://lists.xen.org/xen-devel
>     <https://lists.xen.org/xen-devel>>
>     >     >>
>     >     >> Because it means that xen build needs to download and build
>     a lot
>     >     of 3PP
>     >     >> components. Raisin is already designed to do so (it already
>     >     builds qemu-xen,
>     >     >
>     >     > If you do 'make src-tarball' it will do that for you - and
>     you can
>     >     package
>     >     > all of that in a tarball.
>     >     >
>     >     >> qemu-traditional, libvirt and a few others). I think building
>     >     anything
>     >     >> besides xen proper would fit its scope better.
>     >     >
>     >     > OK, but that does not square well with RPM build systems. Those
>     >     are interested
>     >     > in building just one component (xen+toolstack+its extra
>     pieces). Using
>     >     > raisin to build everything is not going to fly.
>     >     >
>     >     > (Also distros like to seperate componets out - so they build
>     >     qemu-upstream
>     >     > seperate - which is used by Xen - and they could also do it
>     for MiniOS
>     >     > if they were spec files for it and such).
>     >
>     >     There are only few stubdoms you can build without the Xen
>     tree. How
>     >     would you do so for e.g. xenstore-stubdom needing the Xenstore
>     sources
>     >     to be built? Several stubdoms need libxc built for stubdom
>     included.
>     >     And you want to have a build error if e.g. a libxc modification is
>     >     breaking stubdom build.
>     >
>     >
>     >     Juergen
>     >
>     > Hi,
>     >
>     > Raisin already builds xen too, so it has all the dependencies ready.
>     > Regarding the problem of breaking stubdom build by libxc changes I
>     think
>     > those can be prevented if we introduce osstests for raisin build.
>     Maybe
>     > we should start with that, adding raisin to the osstest framework.
>     > Opinions?
> 
>     osstest is too late. I want to see a build error _before_ sending a
>     patch.
> 
>     So how is raisin working exactly? Is it possible to do incremental
>     buils or is the build always complete? Can I start builds of only a
>     subtree? Is it possible to use a private version of some sub-component?
> 
> 
>     You can use private versions easily. Regarding the problem of
>     selective rebuild O think that is missing currently, but given your
>     input it looks important, so I'll look for ways to enable it.
> 
> 
>     I'm not opposed to use raisin e.g. in osstest. I'm opposed to a change
>     in the developer workflow requiring to spend either much more time for
>     testing the build or to add additional steps for it. One-time changes
>     are fine, changes requiring the developer not to forget an additional
>     command are not.
> 
> 
> As raisin is able to build xen and a set of related projects it is
> practically a matter of running raise build rather than make.

Raisin is calling make. I don't think it is appropriate to replace the
"make" call by a raisin call which in turn calls make again.

What I could imagine to be really nice is using raisin to setup the
environment to just build everything:

- configure all components (e.g. replace the manual "configure" by
  raisin)
- download all dependencies instead of doing so during make (using
  local trees should be possible, of course)
- check for needed tools to be all available for doing the actual
  build

This would be a real improvement IMO. A developer could still use make
as usual, while someone just wanting to setup everything from sources
can use "raisin build" for doing all in one step.


Juergen

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

Re: raisin and minios stubdom

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5495 bytes --]

On Mon, 10 Apr 2017, Juergen Gross wrote:
> On 07/04/17 20:54, Géza Gémes wrote:
> > 
> >     On 01/04/17 08:19, Géza Gémes wrote:
> >     >
> >     >
> >     > 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@suse.com
> >     <mailto:jgross@suse.com>
> >     > <mailto:jgross@suse.com <mailto:jgross@suse.com>>>):
> >     >
> >     >     On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
> >     >     > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
> >     >     >>
> >     >     >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
> >     >     >>>> Hi,
> >     >     >>>>
> >     >     >>>> Currently the xen build system has optional support for
> >     >     building a minios
> >     >     >>>> (+needed libraries and tools) based stubdom.
> >     >     >>>>
> >     >     >>>> What is your opinion about moving support for building this
> >     >     into raisin and
> >     >     >>>> once that is stable drop support in the xen build system?
> >     >     >>> Why? I do like doing 'make' and 'make install' and it doing
> >     >     everything
> >     >     >>> for me.
> >     >     >>>
> >     >     >>>> Cheers,
> >     >     >>>>
> >     >     >>>> Geza
> >     >     >>>>
> >     >     >>>>
> >     >     >>>> _______________________________________________
> >     >     >>>> Xen-devel mailing list
> >     >     >>>> Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
> >     <mailto:Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>>
> >     >     >>>> https://lists.xen.org/xen-devel
> >     <https://lists.xen.org/xen-devel> <https://lists.xen.org/xen-devel
> >     <https://lists.xen.org/xen-devel>>
> >     >     >>
> >     >     >> Because it means that xen build needs to download and build
> >     a lot
> >     >     of 3PP
> >     >     >> components. Raisin is already designed to do so (it already
> >     >     builds qemu-xen,
> >     >     >
> >     >     > If you do 'make src-tarball' it will do that for you - and
> >     you can
> >     >     package
> >     >     > all of that in a tarball.
> >     >     >
> >     >     >> qemu-traditional, libvirt and a few others). I think building
> >     >     anything
> >     >     >> besides xen proper would fit its scope better.
> >     >     >
> >     >     > OK, but that does not square well with RPM build systems. Those
> >     >     are interested
> >     >     > in building just one component (xen+toolstack+its extra
> >     pieces). Using
> >     >     > raisin to build everything is not going to fly.
> >     >     >
> >     >     > (Also distros like to seperate componets out - so they build
> >     >     qemu-upstream
> >     >     > seperate - which is used by Xen - and they could also do it
> >     for MiniOS
> >     >     > if they were spec files for it and such).
> >     >
> >     >     There are only few stubdoms you can build without the Xen
> >     tree. How
> >     >     would you do so for e.g. xenstore-stubdom needing the Xenstore
> >     sources
> >     >     to be built? Several stubdoms need libxc built for stubdom
> >     included.
> >     >     And you want to have a build error if e.g. a libxc modification is
> >     >     breaking stubdom build.
> >     >
> >     >
> >     >     Juergen
> >     >
> >     > Hi,
> >     >
> >     > Raisin already builds xen too, so it has all the dependencies ready.
> >     > Regarding the problem of breaking stubdom build by libxc changes I
> >     think
> >     > those can be prevented if we introduce osstests for raisin build.
> >     Maybe
> >     > we should start with that, adding raisin to the osstest framework.
> >     > Opinions?
> > 
> >     osstest is too late. I want to see a build error _before_ sending a
> >     patch.
> > 
> >     So how is raisin working exactly? Is it possible to do incremental
> >     buils or is the build always complete? Can I start builds of only a
> >     subtree? Is it possible to use a private version of some sub-component?
> > 
> > 
> >     You can use private versions easily. Regarding the problem of
> >     selective rebuild O think that is missing currently, but given your
> >     input it looks important, so I'll look for ways to enable it.
> > 
> > 
> >     I'm not opposed to use raisin e.g. in osstest. I'm opposed to a change
> >     in the developer workflow requiring to spend either much more time for
> >     testing the build or to add additional steps for it. One-time changes
> >     are fine, changes requiring the developer not to forget an additional
> >     command are not.
> > 
> > 
> > As raisin is able to build xen and a set of related projects it is
> > practically a matter of running raise build rather than make.
> 
> Raisin is calling make. I don't think it is appropriate to replace the
> "make" call by a raisin call which in turn calls make again.
> 
> What I could imagine to be really nice is using raisin to setup the
> environment to just build everything:
> 
> - configure all components (e.g. replace the manual "configure" by
>   raisin)
> - download all dependencies instead of doing so during make (using
>   local trees should be possible, of course)
> - check for needed tools to be all available for doing the actual
>   build
> 
> This would be a real improvement IMO. A developer could still use make
> as usual, while someone just wanting to setup everything from sources
> can use "raisin build" for doing all in one step.

Yes, that was always the goal. Patches welcome :-)

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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