On Sun, Dec 10, 2000 at 10:58:01PM +0100, beez wrote:
> Would it be possible to build a NetBSD kernel that would run
> in usermode? In fact, would it be possible to build a kernel
> that would run in usermode on top of other OS's (win32, dos32,
> Linux, etc) ?

Possible, probably. Worthwhile? I can't see the use.

> 1. The host OS would need to support threads because the kernel
> would need to rely on a synchronization mechanism from outside
> the kernel (normally provided by the hardware clock) - the clock()
> routine would need to run a seperate thread outside the kernel
> itself.

If you're abstracting the underlying hardware, abstract the clock
too and you won't need this. It seems unreasonable to expect the
same strict behaviours out of a kernel that doesn't control the
hardware.

> 2. Memory protection. I guess this is impossible, kernel and user
> space would be one big malloc()'ed block from the host OS and
> hardware MMU is not available (although a host-process might
> have calls to lock certain parts of memory which the kernel
> can take advantage of) - this means user space programs can
> corrupt kernel memory (a problem yes, but it would still work
> alas somewhat more 'dangerous')

Quick terminology - 
hardware->kernel->l(ayered)kernal->luserland
hardware->kernel->userland

Not impossible I think - just allow a userland process - the
lkernel to specify a malloc request with some ID that the real
kernel could use to set up the MMU with different boundries. It
might even be useful in some other apps - the ability to malloc
multiple chunks, but set your 'ID' to specify which you're allowed
to access at the moment.

> 3. practical problem: Since the kernel is essentially calling
> libc from the host OS - how do I link the host's libc in? Since all
> the libc functions are already defined by NetBSD's libc (e.g.
> two fopen()'s)

I don't understand the issue. How is that different from the kernel/
userland split today?

> 4. Drivers - I don't see a problem here but I might be missing something,
> I guess one could map a ethernet driver to the available networking
> /video/keyboard/whatever functions of the host-OS.

Well, there's a big difference about talking netbsd/netbsd and 
netbsd/(something else). Having control of the bottom layer is crucial
for things like #2. In this - #4, you could do what you say, but you
then have to sacrifice a lot of the functionality in NetBSD -
if NetBSD supports something that the host doesn't, you can't
just pass-through.

> Am I missing something, what other problems would arise if I want
> to port the kernel to usermode? Are/were there any other people
> doing something alike (in BSD land - in Linux land there is already
> the user-mode linux project)

NetBSD would certainly be better suited to this than Linux - we could
have a port-netbsd architecture ;-)

As someone else said though, why?

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Unless you have a solution
when you tell them things like that, most people collapse into a gibbering, 
unthinking mass.  This is the same reason why you probably don't tell your 
boss about everything you read on BugTraq!    - Signal 11