On 10 Nov 2014, at 13:48, Martin Lucina <[email protected]> wrote:
>
> [email protected] said:
>>> This makes sense to me. We use upstream MiniOS now (with some patches to
>>> support installation as a library), so we don't need to do anything
>>> special to benefit from your patches if you submit them upstream. Have
>>> you sent an RFC to xen-devel to get other people's reaction to this? I
>>> can't imagine it'll be too contentious if other uses (such as the qemu
>>> stub domain) are also fixed up to support this.
>>
>> Incidentally, it might help to regenerate your patch stream over the
>> https://github.com/mirage/xen repository. This is a direct mirror of
>> the upstream Xen trees, and we base our Mirage-specific MiniOS off this
>> tree. Also CCing Adam Wick from HalVM as this might help him.
>
> I've not yet proposed an RFC to xen-devel. I think that The patches need a
> bit more work for that to happen:
>
> - As you mentioned, they should be rebased off the upstream mini-os rather
> than the old-ish copy we have in rumprun-xen.
If you rebase them to mirage/xen, we can cook up a development Mirage patch
to test it out in OPAM. Should be fairly mechanical.
> - The patches only rename the bare minumum of APIs and symbols needed by
> rumprun-xen. Notably, I don't rename some macros like
> local_irq_{save|restore} and so on. For these changes to be usable by
> everyone involved we would probably want to do a more thorough
> namespacing?
There's no really clear notion of namespacing here -- it's quite awkward
to have all the macros be prefixed with minios_ just because we can't
control their linkage. On the other hand, local_irq_save is one of the
few macros that *has* to be a macro and not a function, so maybe renaming
it won't be so bad.
I'd recommend getting the existing patchset over to xen-devel as soon as
possible before doing any more work, just to prepare people for it and
make sure there are no blocking objections.
-anil
------------------------------------------------------------------------------
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
