On Fri, 28 Dec 2007, Jared D. McNeill wrote:
>> Does this stuff depend on hardware virtualization features, or is it
>> something that should be a fairly routine (if tedious) port to anything
>> that already runs NetBSD?  (I would think it would be the former,
>> because I have trouble seeing how things like syscalls from user
>> programs could be handled right otherwise, but I've been surprised
>> before....)
>
> No hardware virtualization is required, so it should theoretically work on 
> any hardware that we support.

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. ;)

OK, back to Jared... :)


  - Hubert


[1] http://www.netbsd.org/docs/puffs/rump.html
[2] http://www.netbsd.org/docs/puffs/