On Fri, Nov 7, 2014 at 5:43 PM, Martin Lucina <[email protected]> wrote: > (Re-sending to correct list address..., there is no lists.rumpkernel.org) > > Hi, > > I've been working on cleaning up the Mini-OS namespace so that we can build > arbitrary unmodified software with rumprun-xen without running into > namespace conflicts. > > This work is now pretty much ready for review. You can view the changes on > my Github repository, or I can email the patches to the list if someone > prefers that. > > The changes are located here: > > https://github.com/mato/rumprun-xen/tree/wip-xenos > > It is best to review the individual commits in isolation as especially > ae6aff6 (Clean up Mini-OS public namespace) does a bulk of renaming all > over the rumprun-xen tree. > > These changes also remove the old (non-app-tools based) demo from the > rumprun-xen build. I've added in a simple "Hello World" demo using > Ian's app-tools for testing. We can improve the demos later. > > Note that the 32-bit version of arch-specific xen/arch/x86/x86_32.S has not > been updated with these changes and thus will not build. Someone with a > 32-bit build environment feel free to fix it or I will get around to it > next week. > > Questions: > > 1) Would the upstream Xen folks be interested in these changes? I have > deliberately tried to avoid making any functional changes, and kept the > Mini-OS name and namespace to facilitate merging, despite discussing > various other non-OS names with Antti :-) > > 2) The objcopy command in app-tools/ld is now redundant, right? This was > presumably part of a former attempt at fixing the namespacing issue. > > Any comments or criticism welcome,
It looks good to me, except I would split out the part that builds the test object a bit, so it is easier for people to see where they link their application in (or indeed use this makefile to provide object that they then just do final link to in another makefile). I would post to the openmirage list, as they seem to be the other people using minios - they did the arm fixes, which are not yet upstream. Justin ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
