On Fri Dec 28 2007 at 22:49:49 +0100, Hubert Feyrer wrote:
> If I understood you correctly this afternoon, this works like this:
> the netbsd/userland kernel is a "regular" NetBSD elf binary that runs in 
> userland, just like ls(1) and date(1). The binary is built from NetBSD's 
> src/sys. All the hardware access (that is there right now, which is 
> probably very limited) is replaced with standard libc calls, e.g. to read 
> and write single characters to stdin/stdout where a serial port would be 
> accessed to handle a serial console.
> 
> A related working area where code is also moved from kernel code to 
> userland is the RUMP project[1], which has the main goal of moving file 
> system code into userland, and communicate with the kernel through the 
> puffs[2] interface.
> 
> I guess we can look for more work being done on those two projects, and on 
> the funny side, I wonder if NetBSD's heading into a microkernel that way,
> if everything is running in userland soon. ;)

A few confirmations/clarifications: the scope of rump is supposed to
be beyond file systems.  It just happens to support only them now.
And the idea is to *not* to turn NetBSD into a microkernel, merely
provide options to better develop the system so that it can be run as a
monolithic kernel while in regular use.  The only real reason you would
want to run something outside of the kernel in regular operation is if
the license prevents you from putting it in the kernel (stay tuned ;).
Well, that or you have a strange fetish for wanting things to run slower
than they can...

The differences are that usermode adds a whole virtual operating system,
while rump attaches subsystems directly to the host OS.  So the former
approach is better when you wish to develop a generic kernel feature
which does not depend heavily on the environment (application setup,
hardware, etc.), while the latter requires code specific for that
subsystem (e.g. file systems), but has the benefit of providing the full
host environment.

However, librump has almost 4000 lines of code specific to it to support
various kernel features required for providing the kernel environment
needed to run file systems in userspace.  This is too much.  I am
following Jared's work with great interest and eventually hope to be
able to replace librump with NetBSD/usermode.  It's probably not going
to be trivial, but I hope we'll get there.

As the message passing subsystem putter(9) develops a bit more (it's
currently mostly a quick hack so that puffs and pud can share common
code), we can start adding more support to subsystems (networking,
various hardware device driver interfaces, b/cdev, etc.) to be able to
optionally run components seamlessly in either space using NetBSD/um to
back up their functionality in userspace.

Well, at least that's a rough plan, dunno how it will turn out.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"