[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Fwd: [Xen-devel] RFC: Cleaning up the Mini-OS namespace



The library work is waiting for the ARM patches to be accepted first.
The latest version is on my "devel" branch (which is regularly rebased
against Xen master):

  https://github.com/talex5/xen/commits/devel

In terms of upstreaming, the most obvious thing that needs doing is
modifying Xen's stubdoms to use the library. Currently, they do some
horrible make stuff to reach over and grab what they need from the
extras/mini-os directory...

Ian Jackson (I think) mentioned splitting Mini-OS into a separate
repository, which would help a lot too.


On 13 December 2014 at 20:32, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> Thomas(L),
>
> What's the status of your minios-as-a-library patches that we currently
> have in mirage-xen-minios?  They never got applied upstream did they?
>
> -anil
>
>> Begin forwarded message:
>>
>> Date: 5 December 2014 18:31:53 GMT
>> From: Martin Lucina <martin@xxxxxxxxxx>
>> To: Antti Kantee <pooka@xxxxxx>
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, 
>> rumpkernel-users@xxxxxxxxxxxxxxxxxxxxx, Anil Madhavapeddy <anil@xxxxxxxxxx>, 
>> Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>, Ian Jackson 
>> <ian.jackson@xxxxxxxxxxxxx>, Stefano Stabellini 
>> <stefano.stabellini@xxxxxxxxxxxxx>
>> Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
>>
>> pooka@xxxxxx said:
>>> I wonder if work is minimized if we attempt to merge before or after
>>> we (I?) take the carving knife for a second round in the rumprun-xen
>>> repo to minimize MiniOS to run only on top of itself.
>>
>> Before, I think. Minimizing our copy of Mini-OS duplicates what we would
>> need to do to the upstream copy.
>>
>> I think the steps are roughly as follows:
>>
>>  a) split the current rumprun-xen build out of the Mini-OS Makefile.
>>  b) replace our fork of Mini-OS with the vanilla upstream Mini-OS.
>>  c) re-apply my work and your work, while checking things keep working
>>  with upstream xen.git, until we get rumprun-xen working again.
>>
>> c) will leave us with a set of patches to upstream.
>>
>> Does this make sense? It's a fair amount of work but mostly retracing steps
>> we've already done.
>>
>> It'd help if we had a full list of "what exactly needs to keep working
>> upstream", see my other reply to Andrew. Maybe also osstest building and
>> running Mini-OS related tests off our branch while we do the work? (Ian:
>> ping? Doable?)
>>
>> Martin
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

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