Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
Antti Kantee, le Thu 04 Dec 2014 22:52:05 +, a écrit : Currently, the software stack in rumprun-xen is confusing because MiniOS partially uses libc Which part of libc? MiniOS itself is very independent of libc, it only ships a couple of things. We can probably happily #ifdef them if needed. Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
Antti Kantee, le Sun 07 Dec 2014 18:13:38 +, a écrit : On 07/12/14 18:09, Samuel Thibault wrote: I said it unclearly. I meant the use of #include lotofthings.h (e.g. string.h, stdio.h, etc) ? minios itself doesn't do this when it's not compiled with HAVE_LIBC. Building with HAVE_LIBC is really not a requirement for using mini-os. For rump projects, I would expect not using it, notably. From xen.git/extras/mini-os, irrespective of HAVE_LIBC: netfront.c includes errno.h, That include should actually be #ifdef HAVE_LIBC Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
On 05/12/14 18:31, Martin Lucina wrote: po...@iki.fi 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?) It'd also help if we had a full list of what exactly needs to be done to downstream. That's why I'm not convinced by a list which ignores d) perform the unknown steps to reach our goal (which were painted in broad strokes in my previous mail). Actually, it convinced me more of the opposite: wait before attempting full merge. However, if someone's merge finger is twitching, a pseudo-merge with changes like the namespace protection and introducing a clean libminios split is nice. But, again, is it more or less work doing that piecemeal or when all the puzzle pieces are known? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
andrew.coop...@citrix.com said: I think this is a very good idea, and I am completely in favour of it. There are already-identified issues such as MiniOS leaking things like ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits to fix. I think splitting things like the stub libc away from the MiniOS Xen Framework is also a good idea. Ideally, the result of a MiniOS Build would be a small set of .a's which can then be linked against some normal C to make a minios guest. (How feasible this is in reality remains to be seen.) The approach I used for rumprun-xen is to link all of MiniOS' object files except the startfile into a final .o with ld -r. This then allows me to use objcopy -w -GPREFIX... to make all symbols in minios.o *except* those starting with PREFIX local. This has the advantage that I only had to rename symbols I really wanted to keep global rather than going through all the MiniOS code adding static in places where it was missing and sorting out the resulting inter-dependencies. From a not-public-API point of view, all you have to worry about is that the existing minios stuff in xen.git, including the stubdom stuff, continues to work. We have never made any guarantees to anyone using minios out-of-tree. Existing minios stuff meaning the default build of extras/mini-os? What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses these? Grepping around in stubdom/ doesn't come up with anything... Stubdom stuff meaning the default build of stubdom/, plus the make c-stubdom and make caml-stubdom examples documented in README? Anything else? Sorry if this is obvious but I'm not that familiar with all of xen.git. Thanks, Martin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
On 04/12/14 14:40, Andrew Cooper wrote: There are already-identified issues such as MiniOS leaking things like ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits to fix. I think splitting things like the stub libc away from the MiniOS Xen Framework is also a good idea. Ideally, the result of a MiniOS Build would be a small set of .a's which can then be linked against some normal C to make a minios guest. (How feasible this is in reality remains to be seen.) I've become increasingly convinced that we (rump kernels) would like to use MiniOS as a small firmware library that just takes care of bootstrap and provides a high-level interface to the Xen hypervisor. A componentized MiniOS is not critical from our perspective, as long as you can can compile things out. We always want the minimal version, and can use build flags to produce it. Notably, thanks to recent work by Martin, MiniOS is already compiled to a .o in the rumprun-xen repository, and then just linked into the final image. What is critical for us, however, is reducing the amount of support routines needed by MiniOS. Currently, the software stack in rumprun-xen is confusing because MiniOS partially uses libc which runs on top of the rump kernel which runs on top of MiniOS... This confusion springs from MiniOS providing its own libc, and while it's ok for standalone MiniOS to use its own libc, we do not. To make things as simple as possible, I don't want our [compiled] version of MiniOS to depend on anything from libc. So, while I agree with everyone that merging is a good idea, the realist in me remains in doubt just like you do; is it feasible to both trim MiniOS to be minimal enough for our needs and keep it maximal enough for yours? Or does that result in too many ifdef noodles? From a not-public-API point of view, all you have to worry about is that the existing minios stuff in xen.git, including the stubdom stuff, continues to work. We have never made any guarantees to anyone using minios out-of-tree. 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. - antti ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
