Re: [MirageOS-devel] Mirage on Xen/ARM status

[Thomas Leonard <talex5@xxxxxxxxx>]

On 23 June 2014 23:04, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 23 Jun 2014, at 09:02, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>
>> On 4 June 2014 13:33, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> An update on the Mirage/ARM port:
>> [...]
>>> My current plan is:
>>>
>>> - Upstream Karim's initial ARM support to Xen. I split the original
>>> patch into three smaller ones and submitted them, but they want it
>>> broken up further, which is fair enough.
>>
>> We're going through many of rounds of review with these patches (no
>> major problems - mainly style issues). I'm going to split them up
>> further to make them easier to review.
>
> Thanks for going through the upstreaming so patiently; it's very good
> to know that we're reducing our custom-fork technical debt.

Yeah, I've had 18 patches accepted so far, but we still haven't got to
the ones that actually add ARM support, and those are the big ones!

>>> - Upstream my patches to build a libminios.a library, plus some other
>>> fixes to the build system.
>>
>> The fixes to the build system have been accepted, but the library
>> patches are waiting for the ARM patches to go in first (otherwise
>> we'll get conflicts).
>
>>> - Make some changes to Mini-OS to work unmodified with Mirage
>>> (specifically: expose grant table details, disable interrupt-based
>>> event handlers, and allow linking only the features we need).
>>
>> These are also waiting on the previous patches (and need tidying up).
>>
>> We'll need to make our own release of Mini-OS at some point for Mirage
>> 2.0, and almost certainly before these patches are accepted upstream.
>>
>> The later we do it, the closer it will be to what eventually ends up
>> upstream in Xen. The sooner, the more time we have for testing against
>> it. Does some time this week sound reasonable?
>
> Some time this week sounds great.  Since we now know with reasonable
> certainty that the libminios.a will exist upstream, running with our
> forked version is fine for a while (and possibly forever, if minor local
> patches are needed, or we want to do something like tidy up the console
> logging in such a way that upstream doesn't like it).

I got a bit distracted rewriting the boot code to work on
Xen/unstable. It uses a different memory layout to 4.4, so we need to
detect where we are and program the MMU to fix everything up. It seems
to be working now, though.

>>> - Add a proper string library to mirage-platform to replace Mini-OS's
>>> limited sprintf.
>>
>> I'll probably add the FreeBSD one here.
>
> Ack.

On further investigation, this looks like a lot of work! sprintf uses
vfprintf, which pulls in file stream handling, locales, wchar support,
etc (musl looks similar). I'm currently hacking this all this in to
see how it fits (planning to go back and do it properly once I
understand exactly what's needed), but I'm wondering whether we could
get away with just adding float support to Mini-OS's existing printf
functions? Once OCaml 4.02 comes out, I guess that's all we'll need
anyway.

>>> - Upstream my patches to mirage-platform and mirage to build using the
>>> new libminios and openlibm (these are on github in my forks).
>>
>> How do we want to do this? Can we just tell everyone to upgrade mirage
>> and mirage-platform together, and get Mini-OS and openlibm at the same
>> time, or should we add backwards-compatibility hacks so e.g. mirage
>> can configure for either the old or new version of mirage-platform?
>
> Mirage 1.2.0 will be the last of the 1.x series (except any minor bugfix
> releases), and out this week.
>
> After that, we can merge the 2.0 branch into trunk, which can include the
> Makefile changes needed for the new MiniOS (as well as V2 mirage-types).
>
> There's no need for backwards compatibility hacks between Mirage 1.x and
> 2.x.  The one hitch is that it's not possible to specify a version
> constraint on the command line (e.g. so that `opam install mirage-xen {<2.0}`
> will work), so releasing a new mirage-platform will result in older
> setups breaking if they upgrade.  I'm not sure there's much we can do
> about that beyond instruct users of old Mirage to pin packages, or
> pick a new name such as mirage-platform-xen.  Both are confusing :(
>
>>
>>> - Upstream my Mini-OS ARM patches to Xen.
>>
>> I squashed these into Karim's ARM patches to simplify the review (no
>> point reviewing code that's about to be replaced).
>>
>>> - Add a start_info structure on ARM, or find some other way to expose
>>> those details to Mirage.
>>
>> This is done, and simplified things greatly. No changes are now needed
>> in mirage-console, etc for ARM.
>>
>> We also need to sort out the ones complement stuff for networking on
>> ARM, but that can come after the upgrade to the new Mini-OS (which is
>> the big change; once we have that, ARM support comes almost for free).
>
> Agreed!

BTW, did anyone manage to test my current preview branches (i.e.
mirage-platform + libminios)?


-- 
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