[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 0/5] Split off mini-os to a separate tree
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |