On 21/01/15 22:32, Nick Hardiman wrote:
> This is my first question here, so be ready for a stupid one!
>
> What's been run on rump kernels? Maybe test suites, lang.interpreters, 
> popular servers?
>
> e.g.  test suites (fsx), lang.interpreters (luajit), popular servers (thttpd)?

Nick,

It's not a stupid question, but let me anyway give you a stupid 
(abstract) answer.

The problem with writing OS's or OS-like stacks is that they need to be 
real world bug-compatible to be able to reliably run the real world 
(i.e. buggy) software that you throw at them.  Since we use *unmodified* 
real world OS components as the base, the layers are real world 
compatible as-in, and things tend to just work.

As we saw with Mato Lucina's recent php+httpd experiment, there are a 
few problematic scenarios:

1) anything which relies on "unlimited" virtual memory or exec/fork/mmap
2) non-standard build tools which prevent app-tools from just working
3) some minor bugs haven't managed to tickle yet

For "1", we can adjust things to some extent, but it's really a 
fundamental incompatibility with a no-virtual-memory execution model. 
As the "NoOS" scheme picks up more, I think more applications will veer 
toward compatibility.

For "2", we'll keep on improving our build systems.  Note, the build 
system is more or less just cross-compilation, but unfortunately not all 
software supports that in an easy way, so there's only so much we can do 
here -- native compilation on a rump kernel sounds like a nonstarter.

For "3", we can more or less fix things as fast as people just keep 
reporting them.  Again, given that we are already using unmodified 
bug-compatible code, these are typically trivial fixes along code paths 
that nobody has exercised yet in a rump kernel.  I have high confidence 
in rump kernel stability.  After all, the kernel part was declared 
stable 4 years ago (but back then nobody had the clairvoyance to see the 
need for the "userspace" part, i.e. libc et. al).

There's apparently also a tendency for servers to only support 
dynamically loaded plugins.  I was not aware of this earlier!  We could 
*theoretically* add a dynamic loader (the rump kernel already supports 
one which I did as a silly experiment years ago), but I think simplicity 
and static linking in the application build systems would be the way to 
go there.

I hope others will chime in with more concrete stories.

Going the other way, if you or someone else has a suggestion for 
something that doesn't trip on "1" that we should look into, I'm all 
ears!  The roadmap, after all, is more or less summarized as "test stuff".

   - antti

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users

Reply via email to