Re: [Xen-devel] raisin and minios stubdom

[Stefano Stabellini]

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"  > 
> > > >>):
> > >
> > > 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?
> > 
> > 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. 

Re: [Xen-devel] 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"  
> > >>):
> >
> > 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?
> 
> 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 

Re: [Xen-devel] raisin and minios stubdom

[Géza Gémes]

On 01/04/17 08:19, Géza Gémes wrote:
>
>
> 2017. márc. 31. 16:15 ezt írta ("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
>
> 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] 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  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,  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: [Xen-devel] 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  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,  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: [Xen-devel] raisin and minios stubdom

[George Dunlap]

On Mon, Mar 27, 2017 at 8:28 PM, 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?

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,  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: [Xen-devel] 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"  >):
> 
> 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?

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: [Xen-devel] raisin and minios stubdom

[Gémes Géza]

2017-04-01 08:19 keltezéssel, Géza Gémes írta:



2017. márc. 31. 16:15 ezt írta ("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

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

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

Re: [Xen-devel] raisin and minios stubdom

[Géza Gémes]

2017. márc. 31. 16:15 ezt írta ("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

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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] 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: [Xen-devel] 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: [Xen-devel] 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