Re: [Xen-API] [Xen-users] rump kernels running on the Xen hypervisor

[Antti Kantee <pooka@xxxxxx>]

On 17.8.2013 17:17, Ian Campbell wrote:
> Sounds really cool! What sort of applications have you tried this with?
With rump kernels hosted on POSIX systems, I've tested "everything", 
e.g. TCP/IP with firefox and sshd, file systems with ls, tar, etc., both 
for nfs, and so forth.  When hosted on mini-os, things will be a bit 
different.  Let me elaborate below.
> Does this provide enough of a posix like system (libc etc) to run
> "normal" applications or do applications need to be written explicitly
> for rump use?
Like the name suggests, a rump kernel is a kernel with some pieces 
missing.  I've sometimes (jokingly?) described a rump kernel as KaaS 
(kernel-as-a-service), because an application can request services from 
a rump kernel, but a rump kernel will not directly affect the 
application -- think exec, fork, mmap, signals, etc. which are provided 
by "normal" kernels but do not fit into a request-response model.
The first problem with complex applications is going to be their use of 
fork, exec, userspace threads, dlfun etc.  For example, sshd does quite 
a few tricks with execs and forks when it starts.  When running on a 
POSIX host, these interfaces come from the host even if sshd uses a 
TCP/IP service provided by a rump kernel.  When the rump kernel 
container is a Xen domU instead of a process, well, I'm not sure how to 
define exec for a domU, and doubly so for exec's fd semantics ...
The second, and easier, problem is that "libc etc" is not included in 
the scope of rump kernels and has to come from somewhere else.  The good 
news is that the syscall stubs provided by rump kernels are fully 
compatible with the POSIX'y API and could be used as such (look at 
<rump/rump_syscalls.h> if curious).  The non-syscall bits would still 
have to appear from somewhere.  I noticed mini-os has a HAVE_LIBC 
conditional, but I did not yet look into how much that would provide of 
"libc etc".
So, to answer your question, applications do not need to be explicitly 
written to use rump kernels, but all of the interfaces used by 
applications need to of course be provided somehow.  You conceivably 
could run e.g. a simple web server very easily (especially one which 
uses an event loop over user threads or fork), but I wouldn't bet on 
firefox running on top of mini-os/rump kernel anytime soon.
> What I'm wondering is if this would be a more maintainable way to
> implement the qemu stub domains or the xenstore one?
I've played with Xen only for a few days now, so I've yet to discover 
what the maintenance problem with the current implementation is.  If you 
can elaborate, I can reciprocate.
> > less than 1k lines of code including
> > comments and whitespace, I hope I haven't managed to cram too many bugs
> > in there.
> I think the usual statistic is that 1000 line should only have a few
> dozen bugs ;-D
My approach for beating the odds: more comments and whitespace ;)

> Ian Jackson has also been looking at these sorts of issues with mini-os
> recently, I'll let him comment on where he has gotten to etc.
>
> I think as a general rule we'd be happy with any cleanups made to
> mini-os.
Nice.  I'd be happy if I can strip out the mini-os bits from by github 
repo and somehow make my work pluggable into upstream mini-os.
_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api