Re: [Xen-devel] [PATCH RFC 0/5] Split off mini-os to a separate tree

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jan 27, 2015 at 01:18:02PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Wei Liu, le Sun 25 Jan 2015 18:13:41 +0000, a écrit :
> > There has been increasing use of mini-os in unikernel world and basically
> > everybody has their own fork of mini-os. That way going foward is going
> > to cause fragmentation of the community.
> > 
> > We would like to split off mini-os tree so that everybody can upstream their
> > changes and work on a common code base. Later I would also like to setup
> > a proper push gate for mini-os.
> 
> Definitely agreed!
> 
> > Stubdom's build environment is known to be very fragile, so basically all 
> > the
> > real work is done in top level Makefile.
> 
> I'm wondering about the relation between mini-os and stubdom: will
> we assume that they are developped and released together?  For now

For now I think it makes sens to release mini-os and Xen coupled, so
stubdom and mini-os are in effect developed and released together.

> we could add something to mini-os and use it in stubdom/ without
> caring about backward compatibility in either way.  If the two get
> developed independently we may encounter issues, particularly if
> stubdom/ downloads mini-os rather than taking the source alongside. I'm
> wondering whether stubdom/ should be put in the same repository as

That's a bit overkill IMHO. People interested in mini-os don't
necessarily have much interest in stubdom.

In fact, stubdom should be treated as a downstream of mini-os as with
any other unikernel. This can help us discover any dishonesty in API
design and code.

> mini-os; in that case we reverse the situation: it's things like libxc &
> xenstore which need to be downloaded instead, I wonder to which extend
> it is less coupled with mini-os than stubdom/: libxc does use some
> systems functions of mini-os (alloc_fd, map_frames_ex, mask_evtchn,
> etc.), perhaps stubdom/ could contain the xc_minios.c file for building
> libxc, and the interface between the mini-os repo and the xen repo would
> then be the xc_osdep_ops structure. That sounds a more viable interface
> on the long run than the minios system interface, what do people think?
> 

Unfortunately we can't do that, because xc_minios.c depends on some
libxc internal interface (it includes xc_private.h).

Wei.

> Samuel

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