On 07/11/14 17:43, Martin Lucina wrote: > (Re-sending to correct list address..., there is no lists.rumpkernel.org)
maybe some day ... > 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. Ok by me conceptually -- I didn't read the diffs line-by-line, as they seem mostly straightforward. > 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. tests/configure already does more or less the same thing, except that it checks that autoconf works too. > 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. Can't you build it with your current toolchain using -m32? (if you can, -m32/-m64 should probably be added to the travis build matrix) > 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 :-) expanding: i'd like to avoid using "os" for what is conceptually the firmware layer in the rumprun stack. there's also a few bits in the current minios that we use across the board (scheduler and threads). it would be nice to figure out a more generic name for them. > 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, thank you for doing this important work! ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
