Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)
Ian, Thank you for the explanations. Hmm. (not replying to anything specific) My guess is that shared libs won't be the biggest problem. I'd find it extremely surprising if you can take a Linux (or any other !NetBSD) packaging system and discover the dozens of dependencies of QEMU to not contain any "'isms" which do not apply when building for what is essentially a NetBSD target. I don't know how Wei Liu built his QEMU, but I assume it was by farming a lot of --disable-stuff. That's what I'd do and somehow find a way to ship the result. The requirements for stubdom QEMU and /usr/bin/qemu are IMO too dissimilar to stuffed into the same box. By my judgement (which may be wrong), almost none of the dynamic dependencies of QEMU on a regular Linux system apply for the Xen stub domain use. If the goal is to get a reduced footprint qemu, bundling unnecessary clutter is in direct conflict with the goal. Besides, trying to get e.g. libsystemd to build or work with [a NetBSD-API'd] Rumprun will most likely earn you a ticket to the loony bin. So while I think I understand your predicament (you need to sell the Xen improvement to distros which means playing by their rules) and the temptation of reusing existing packages for the job, I seriously doubt the approach will lead to a sensible result. That, of course, shouldn't stop you from trying. If the result of your experimentation matches your hypothesis and shared libs is the main problem, I'll figure out a way to make it work on the Rumprun side of things. If you truly decide you need to use existing Linux infra, I'd start down that track by bolting a Linux userspace environment on top of the "kernel only" Rumprun stack (which could/should more or less work thanks to syscall emulation). Of course, you'd need to do the same for FreeBSD and every other system you want to support, so it's not a free ticket either, but by my guess at least a cheaper one. Anyway, I only have guesses. - antti ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)
On 08/09/15 16:15, Ian Campbell wrote:
On Tue, 2015-09-08 at 15:03 +, Antti Kantee wrote:
For unikernels, the rump kernel project provides Rumprun, which can
provide you with a near-full POSIX'y interface.
I'm not 100% clear: Does rumprun _build_ or _run_ the application? It sound
s like it builds but the name suggests otherwise.
For all practical purposes, Rumprun is an OS, except that you always
cross-compile for it. So, I'd say "yes", but it depends on how you want
to interpret the situation. We could spend days writing emails back and
forth, but there's really no substitute for an hour of hands-on
experimentation.
(nb. the launch tool for launching Rumprun instances is currently called
rumprun. It's on my todo list to propose changing the name of the tool
to e.g. rumprunner or runrump or something which is distinct from the OS
name, since similarity causes some confusion)
Do these wrappers make a rump kernel build target look just like any other
ross build target? (I've just got to the end and found my answer, which was
yes. I've left this next section in since I think it's a nice summary of
why it matters that the answer is yes)
e.g. I have aarch64-linux-gnu-{gcc,as,ld,ar,etc} which I can use to build
aarch64 binaries on my x86_64 host, including picking up aarch64 libraries
and headers from the correct arch specific patch.
Do these rumprun-provided wrappers provide x86_64-rumpkernel
-{gcc,as,ld,ar,etc} ?
No, like I said and which you discovered later,
x86_64-rumprun-netbsd-{gcc,as,ld,ar,etc}. aarch64 would be
aarch64-rumprun-netbsd-{...}.
Appearing as a regular cross-compilation target is, I think, going to be
important to being able to create rumpkernel based versions of distro
packages.
I think that package maintainers ideally won't want to have to include a
bunch of rumpkernel specific code in their package, they just want to
leverage the existing cross-compilability of their package.
Yes, that is critical. We bled to achieve that goal. It looks obvious
now, but I can assure you it wasn't obvious a year ago.
$ ldd /usr/bin/qemu-system-x86_64 | wc -l
87
$
Heh, that's quite a lot.
If the above didn't explain the grand scheme of things clearly, have a
look at http://wiki.rumpkernel.org/Repo and especially the picture. If
things are still not clear after that, please point out matters of
confusion and I will try to improve the explanations.
I think that wiki page is clear, but I think it's orthogonal to the issue
with distro packaging of rump kernels.
Sure, but I wanted to get the concepts right. And they're still not
right. We're talking about packaging for *Rumprun*, not rump kernels in
general.
However, since a) nobody (else) ships applications as relocatable
static objects b) Rumprun does not support shared libraries, I don't
know how helpful the fact of ABI compatibility is. IMO, adding shared
library support would be a backwards way to go: increasing runtime
processing and memory requirements to solve a build problem sounds plain
weird. So, I don't think you can leverage anything existing.
This is an interesting point, since not building a shared library is
already therefore requiring packaging changes which are going to be at
least a little bit rumpkernel specific.
Is it at all possible (even theoretically) to take a shared library (which
is relocatable as required) and to do a compile time static linking pass on
it? i.e. use libfoo.so but still do static linking?
But shared libraries aren't "relocatable", that's the whole point of
shared libraries! ;) ;)
I guess you could theoretically link shared libs with a different ld,
and I don't think it would be very different from prelinking shared
libs, but as Samuel demonstrated, it won't work at least with an
out-of-the-box ld.
I think it's easier to blame Solaris for the world going bonkers with
shared libs, bite the bullet, and start adding static linking back where
it's been ripped out from. Shared libs make zero sense for unikernels
since you don't have anyone to share them with, so you're just paying
extra for PIC for absolutely no return. (dynamically loadable code is a
separate issue, if you even want to go there ... I wouldn't)
I don't really have good solutions for the packaging problem. Building
a "full distro" around rump kernels certainly sounds interesting,
FWIW I don't think we need a full distro, just sufficient build
dependencies for the actual useful things (maybe that converges on to a
full distro though).
By "full distro" I meant "enough to get a majority of the useful
services going". Seems like once qemu works, we're 99% there ;)
Debian are (most likely) not going to accept a second copy of the QEMU
source in the archive and likewise they wouldn't want a big source package
which was "qemu + all its build dependencies" or anything like that,
especially when &quo
Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)
Hi, Wei Liu hinted that I should "chime in and / or provide corrections" (his words). I'll attempt to do exactly that by not really replying to anything specific. For the record, when I say "we" in this mail, I mean "people who have contributed to the rump kernel project" (as also indicated by the email-hat). First of all, there's a difference between a rump kernel (driver bundle built out of unmodified kernel components) and any unikernel you construct out of rump kernels ... sort of like how there's a difference between Linux and GNU/Linux. For unikernels, the rump kernel project provides Rumprun, which can provide you with a near-full POSIX'y interface. Rumprun also provides toolchain wrappers so that you can compile existing programs as Rumprun unikernels. Rumprun also recently regrew the ability to run without the POSIX'y bits; some people found it important to be able to make a tradeoff between running POSIX'y applications and more compact "kernel plane" unikernels such as routers and firewalls. But, for brevity and simplicity, I'll assume the POSIX'y mode for the rest of this email, since that's what the QEMU stubdom will no doubt use. If the above didn't explain the grand scheme of things clearly, have a look at http://wiki.rumpkernel.org/Repo and especially the picture. If things are still not clear after that, please point out matters of confusion and I will try to improve the explanations. Also for simplicity, I'll be talking about rump kernels constructed from the NetBSD kernel, and the userspace environment of Rumprun being NetBSD-derived. Conceptually, there's nothing stopping someone from plugging a GNU layer on top of NetBSD-derived rump kernels (a bit like Debian kXBSD?) or constructing rump kernels out of Linux. But for now, let's talk about the only working implementation. As far as I know, the API/ABI of the application environment provided by Rumprun is the same as the one provided by standard NetBSD. Granted, I didn't perform the necessary experiments to verify that, so take the following with a few pinches of salt. In theory, you could take application objects built for NetBSD and link them against Rumprun libs. However, since a) nobody (else) ships applications as relocatable static objects b) Rumprun does not support shared libraries, I don't know how helpful the fact of ABI compatibility is. IMO, adding shared library support would be a backwards way to go: increasing runtime processing and memory requirements to solve a build problem sounds plain weird. So, I don't think you can leverage anything existing. We do have most of the Rumprun cross-toolchain figured out at this point. First, we don't ship any backend toolchain(s), but rather bolt wrappers and specs on top of any toolchain (*) you provide. That way we don't have to figure out where to get a toolchain which produces binary for every target that everyone might want. Also, it makes bootstrapping Rumprun convenient, since you just say "hey give me the components and application wrappers for CC=foocc" and off you go. *) as long as it's gcc-derived, for now (IIRC gcc 4.8 - 5.1 are known to work well, older than that at least C++ won't work). clang doesn't support specs files at least AFAIK, so someone would have to figure out how to move the contents of the specs into the wrappers, or whatever equivalent clang uses. (patches welcome ;) The produced wrappers look exactly like a normal cross-toolchain. The tuple is the same as what NetBSD uses, except with rumprun added in the middle, so e.g. x86_64-rumprun-netbsd or arm-rumprun-netbsdelf-eabihf. That naming scheme means that most GNU-using software compiles nicely for Rumprun just by running configure as ./configure --host=x86_64-rumprun-netbsd followed by "make". Sometimes you additionally need things like --disable-shared, but all in all everything works pretty well. See http://repo.rumpkernel.org/rumprun-packages for a bunch of "case studies", not limited to just GNU autotools. After "make", before launch we have an additional step called "bake", which links the specific kernel components onto the binary. So for example, you can make the compiled binary run on Xen or KVM depending on which kernel components you bake onto it. As a crude analogy, it's like scp'ing a binary to a Xen or KVM or bare metal system, but since the Rumprun unikernel is missing exec, we use the linker to perform "system selection". So for shipping, one option is to ship the binary after "make", but then you also need to ship the toolchain. The other option is to ship the baked binary, but then you lose some of your possibilities on how to target the binary. I'm not sure either option is right for all cases. We're still trying to figure out the exact form and figure of bake+launch. In the original implementation we assumed that at launch-time we could cheaply control all of the details of
Re: [Xen-devel] [PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and provide some stable libraries
On 10/06/15 16:15, Wei Liu wrote: On Wed, Jun 10, 2015 at 05:01:27PM +0100, Ian Jackson wrote: Ian Campbell writes ([PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and provide some stable libraries): [stuff] Most of this looks good to me. As part of this change I've begun to get rid of the osdep interface layer, since it is obsolete and just gets in the way. IIRC there were some tricks being played to use this on rumpkernels to mix and match facilities from xc_minios.c and xc_netbsd.c. Replacing those tricks with appropriate #ifdefs would be fine. FYI I think I will write more glue code to make rump kernel to just use netbsd code, because they don't want to expose underlying minios functionalities to application level. It's not so much that we outright don't want to as prefer not to. If there's a strong reason, e.g. a measurably significant performance improvement, then we can talk. However, anything calling past the libc interface is dipping into internal interfaces. We make no guarantee about internal interface stability. One good summary of 8 years of rump kernel development would be lack of compartmentalization always comes back to bite you, so IMO it's better to conceptually maintain separation even where not enforced by a MMU and just make everything go through the guaranteed-stable syscall interfaces. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] OSSTEST: introduce a raisin build test
On 06/05/15 11:03, Stefano Stabellini wrote: On Wed, 6 May 2015, Ian Jackson wrote: Stefano Stabellini writes (Re: [PATCH] OSSTEST: introduce a raisin build test): That's fine as there is no hidden git cloning with raisin. All the trees are specified explicitly in the config file. Is this a fundamental design principle ? The rump kernel build system uses git submodules, which are (very annoying and) a kind of hidden git cloning, and it also has a [psuedo-submodule a bit like xen.git wrt qemu et al. Oh dear lord. I am keeping not having hidden git cloning as a fundamental design principle and goal of the project. I haven't tried to integrated rump kernels into raisin yet, but as I told you IRL, I have been thinking of writing the build system in a way that the git cloning is done by raisin, even for rump kernels. Well, these days it pulls the submodules in if they're not already present. If you pull them in manually before running the build script, no hidden cloning happens. Given that you want to pull them in manually anyway, I don't see a problem. It's actually more of a historic remnant from times when checking out the necessary sources was a non-trivial operation involving separate user/kernel repositories and copying/patching sources all around. I think it was fixed over a year ago. I guess I could remove the git submodule update detection/execution from the build script entirely. It's sort of illogical that you don't have to execute it after you clone initially but realistically speaking have to execute it after every pull -- makes us look like drug dealers. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [rumpuserxen test] 52955: regressions - FAIL
On 02/05/15 03:00, osstest service user wrote: flight 52955 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/52955/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 These tests have been failing for a while now. At least part of the problem is that they're run against the old repository where the build script is essentially echo use new repo; exit 1;. As such, continuing to run them is not useful (*). Hopefully we can make an effort to convert them to use the new repo ASAP and at the same time also agree on what the tests are allowed to assume to be stable interfaces. - antti *) but I have to admit, they did catch a quoting bug in the use new repo error message: https://github.com/rumpkernel-attic/rumprun-xen/commit/3b91e44996ea6ae1276bce1cc44f38701c53ee6f ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel
On 18/03/15 11:22, Martin Lucina wrote:
po...@rumpkernel.org said:
etfs isn't a file system, e.g. it doesn't allow listing files or
removing them, but it does give you complete control of what happens
when data is read or written for /some/path. But based on the other
posts, sounds like it might be enough for what you need.
See:
http://man.netbsd.org/cgi-bin/man-cgi?rump_etfs++NetBSD-current
They'd still need to implement the rumphyper/Mini-OS backend to get etfs to
talk over vchan to the dom0, right?
Strictly speaking, they'd have to implement the iov{read,write}
hypercalls to do that. But, no, etfs doesn't do magic. IOW, they'd
have to define what host path means.
It occurred to me that I wrote that manpage, umm, 5 years ago when rump
kernels ran only in userspace and host path was a better defined term.
Pile that manpage on the neverending heap of documentation which broke
while the code kept working.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel
On 18/03/15 21:21, Anil Madhavapeddy wrote: This is not an argument for or against; if you want to expose AF_WHATEVER to applications running on a rump kernel, you need to sell AF_WHATEVER to NetBSD, not to rumpkernel-users. Well, preferably you need to sell it to everyone implementing sockets and running on some sort of hypervisor, but of course gotta start from somewhere. Given that most of the uses of this will be in userspace code, just faking out AF_UNIX in Rump does seem a lot easier. It doesn't matter to MirageOS either way -- we just need a well-defined XenStore/ring protocol to obey to do connection setup on the other side. Where do you propose to inject that faking out (and what does it even mean)? Someone at Berkeley decided that socket drivers should be globally enumerated, and PF_UNIX leads to exactly one handler. Just hacking hooks as local patches into the PF_UNIX driver is against the whole point of having unmodified, tested drivers from upstream. So, if you want your bus to appear as a socket to userspace, I don't see any shortcut to not going via NetBSD. If you're happy with something else than a socket, that's another story. Especially if the interface doesn't matter too much for whatever purpose you plan to use it for, it's silly to specify the interface so that the implementation process is as convoluted as possible ;) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel
On 17/03/15 14:29, Wei Liu wrote: I've now successfully built QEMU upstream with rump kernel. However to make it fully functional as a stubdom, there are some missing pieces to be added in. 1. The ability to access QMP socket (a unix socket) from Dom0. That will be used to issue command to QEMU. 2. The ability to access files in Dom0. That will be used to write to / read from QEMU state file. There's a way to map file access to rump kernel hypercalls with a facility called etfs (extra-terrestrial file system). In fact, the current implementation for accessing the Xen block device from the rump kernel is done using etfs (... historical reasons, I'd have to go back 5+ years to explain why it doesn't attach as a regular block device). etfs isn't a file system, e.g. it doesn't allow listing files or removing them, but it does give you complete control of what happens when data is read or written for /some/path. But based on the other posts, sounds like it might be enough for what you need. See: http://man.netbsd.org/cgi-bin/man-cgi?rump_etfs++NetBSD-current 3. The building process requires mini-os headers. That will be used to build libxc (the controlling library). That's not really a problem, though I do want to limit the amount of interface we claim to support with rump kernels. For example, ISTR you mentioned on irc you'd like to use minios wait.h. It would be better to use pthread synchronization instead of minios synchronization. That way, if we do have a need to change the underlying threading in the future, you won't run into trouble. So, we should just determine what is actually needed and expose those bits by default. One of my lessons learned from the existing stubdom stuffs is that I should work with upstream and produce maintainable code. So before I do anything for real I'd better consult the community. My gut feeling is that the first two requirements are not really Xen specific. Let me know what you guys plan and think. Yes, please. If there's something silly going on, it's most likely due to: 1) we didn't get that far in our experiments and weren't aware of it 2) we were aware, but some bits were even sillier, taking priority Either way, a real need is a definite reason to expedite fixing. - antti ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [rumpuserxen test] 35897: regressions - FAIL
On 06/03/15 10:49, Ian Campbell wrote: A new one to me: + cp 'rumpuserxen/rump-kernel*' dist/usr/local/lib/xen/rump-kernel cp: cannot stat `rumpuserxen/rump-kernel*': No such file or directory We think we figured out how to actually do things, and some repo-reorganizing was mandated. The churn causes some of these failures -- though, let's admit it, the tests were already failing before the churn. Hmm, would it be possible to codify what osstest needs to execute in the rumprun repo, e.g. in form of a defined script name? That way we could just edit the script when doing changes (e.g. adding tests) instead of having to go back-and-forth between your repo and ours? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [rumpuserxen test] 34575: regressions - FAIL
On 15/02/15 18:51, xen.org wrote: flight 34575 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34575/ Regressions :-( This looks like a new failure: === snip === checking for ncurses.h... no configure: error: Unable to find a suitable curses library configure: error: ./configure failed for tools === snip === http://www.chiark.greenend.org.uk/~xensrcts/logs/34575/build-amd64-rumpuserxen/6.ts-xen-build.log ? Can we work around it somehow? I guess nobody wants to run the tools on a rump kernel. Or am I completely misguessing what the tools are for? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] GPF Heisenbug with rumprun-xen
On 05/02/15 15:51, Ian Jackson wrote: It looks to be some sort of Heisenbug in the rump kernel stuff. I agree. We had a failure on the 16th of January which looked like some kind of race: (Subject: Re: [Xen-devel] [rumpuserxen test] 33416: regressions - FAIL) Aha! I told you I don't believe in cosmic rays ;) This http://www.chiark.greenend.org.uk/~xensrcts/results/history.test-amd64-amd64-rumpuserxen-amd64.html show a history of random failures at the xenstorels step. At least the ones as far back as 33830 (the last one with logs still available) all show signs of what looks like memory corruption of some sort. Thanks for the digging. (I have left the quoted text in for the benefit of rumpkernel-users.) The first failure in that history that looks like part of this is flight 33690. We don't have logs for that any more but it used rumpuserxen 598ceb54916b xen 49de0b57b853 netbsdsrc 17a547ca2943 Failure probability after then seems about 20%. If I go back 10 passes from 33690 I get to 33611 which used rumpuserxen ffcd777f8062 xen 0d2879062076 netbsdsrc a7c6b12e1752 It seems unlikely that the difference is g oing to be due to changes in the versions of linux, linuxfirmware, ovmf, qemu[u] or seabios. buildrump.sh has been 47b1a5eef43c throughout. The diffs for rumpuserxen and netbsdsrc between those revisions are luckily small. I couldn't spot anything in there which would immediately look suspicious. The most suspicious change is calling sched_yield() as part of the bootstrap process, but that's not very dramatic as far as suspicious goes. TLS support was added, but I'm not sure how that would affect threads which do not use TLS. That said, TLS did work right off the bat, so it is a bit suspicious ... Is it possible that some change in xen is tickling the bug? That would explain why attempts to reproduce the bug in other setups have failed. Is it easy to fire off runs with arbitrary revisions of each repo? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] ts-rumpuserxen-build: Use new app-tools
On 04/02/15 14:33, Ian Jackson wrote: Ian Campbell writes (Re: [PATCH] ts-rumpuserxen-build: Use new app-tools): On Wed, 2015-02-04 at 12:36 +0100, Martin Lucina wrote: Update to use the new app-tools names. I'm not sure if we need to support bisection over this change -- but I think we probably do (Ian?) in which case we would need to probe for which one actually exists, preferring the newer name. It's not just bisection; our push gate will fail because of the lack of compatibility. So we need to probe. I will prepare a patch. Can the grievous-bodge grievances now be removed, or are prehistoric revisions still required to build? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [rumpuserxen test] 33416: regressions - FAIL [and 1 more messages]
On 16/01/15 11:17, Ian Jackson wrote: The latter is the GPF turning out to be unreproducible. I guess we should keep an eye out in case it turns out to be a race rather than a cosmic ray. I do not believe in cosmic rays. Some notes in case it resurfaces: 1) the topmost caller address appears to be on the stack (??) 2) calling main() seems to be output properly, the next line (running demos) doesn't. there is exactly one function call (~20 instructions) between these two lines 3) the first printf goes to stderr, while the second, supposedly failing one, goes to stdout (no idea why) 4) it's crashing calling fp-_swrite(). notably, the execution of __sflush() might or might not go that far if fp upon entry points to garbage (existing garbage, not page faulting garbage) 5) the call is made as: 6018b: 41 ff 54 24 50 callq *0x50(%r12) from the output: R12: e02b (e02b is somewhere in the middle of xenbus_xb_write, highly unlikely to be relevant, more likely to be some random garbage) from the image: rump-kernel$ nm rump-kernel | grep __sF 00299d60 D __sF (stdout is __sF[1]) There are no (user) threads active yet. I currently have no theories how the failure is reachable, at least assuming that the console output is accurate. I still don't believe in cosmic rays, though ;) ___ 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
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
Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks from Xenstore
On 13/11/14 17:07, Martin Lucina wrote: po...@iki.fi said: Actually, hmm, there's already an image for /etc available. I understood from irc discussion that you needed slight modifications to passwd for mathopd. In case your changes don't conflict with what's already up there, you could just update the existing downloadable /etc image: https://github.com/rumpkernel/rumprun-xen/tree/master/img I'll add in a new image rather than touch the current one, so that it can be cd9660 and read-only rather than ffs. Avoids needing to keep a clean image around in case of crashes while developing. The old one can stay until we replace the old demo code. Generally speaking, file systems support read-only mounts ... Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer that it's not supposed to be used as a normal /etc. I'd prefer it to be completely hidden from the user. But sure, call it stubetc for now. This brings up another question; what to do with resolv.conf, for example? Is resolv.conf an example, i.e. are there other files with similar needs? Or can we figure out how to handle it as a special case? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
