[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.