[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 27 Jan 2015, at 11:52, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> On Mon, Jan 26, 2015 at 10:57:57AM +0000, Anil Madhavapeddy wrote:
>> On 26 Jan 2015, at 09:53, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> [ Cc += Anil ]
>>> On 25 January 2015 at 18:25, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>>>> Cc Ian and Ian and some folks who might be interested in this work.
>>>> On Sun, Jan 25, 2015 at 06:13:41PM +0000, Wei Liu wrote:
>>>>> 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.
>>>>> Stubdom's build environment is known to be very fragile, so basically all 
>>>>> the
>>>>> real work is done in top level Makefile.
>>>>> I use following runes to split off mini-os:
>>>>> git filter-branch --tag-name-filter cat \
>>>>>   --subdirectory-filter extras/mini-os/ -- --all
>>>>> # There is already a tag name 4.3.0-rc2 which points to the same commit.
>>>>> git tag -d xen-4.3.0-rc2
>>>>> # Add xen- prefix to all tags
>>>>> for t in `git tag`; do git tag "xen-$t" "$t"; git tag -d "$t" ; done
>>>>> git gc --aggressive
>>>>> The tree can be found at:
>>>>> git://xenbits.xen.org/people/liuw/mini-os.git master
>>>>> Note that mini-os cannot build on its own due to the limitation of it's 
>>>>> own
>>>>> build system. Splitting it off it's the first step towards fixing that 
>>>>> problem
>>> In case it's useful: for the standalone version of Mini-OS used by
>>> Mirage, I had to include these directories too:
>>> 1. xen/include/public
>>> 2. xen/common/libfdt
>>> 3. xen/include/xen/libfdt
>>> 4. config
>>> ( https://github.com/talex5/xen/tree/minios-releases )
>> It would be useful if the work to split out MiniOS could be done in
>> the xen.git tree, so that it ends up building completely standalone
>> and there's a final changeset in xen.git.
> I would rather take the other approach -- split out first than fix
> problems as we go.

That makes reconciling some of these long running forks annoying,
since they branched off xen.git.  It doesn't matter if you split/fix
in any order, but it's nice to have one changeset against xen.git that
breaks out the build dependencies so that extras/mini-os builds
independently from the Xen Makefile infrastructure, and then another
that deletes MiniOS (which of course will not be in the split repo).

> Splitting should be done sooner in the release cycle rather than later
>> What's the planned release schedule for the new MiniOS?  Independent
>> of Xen or initially coupled?
> My initial thought is that we should start coupled. Releasing
> independently requires more man power than releasing coupled. Of course
> the option to release independently is always available.

That all makes sense to me.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.