Hi David,

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

Well at first it was more of a 'can it be done' kind of thing,
but as time progressed I do start seeing possible uses (apart
from the fact that it would be just plain fun - but maybe I'm
too geeky :-)

possible uses could be: trying out 'dangerous' stuff in a kernel. Having an
even more secure layer for possible malicious userspace programs (basically
a kernel 'chroot'), if one could port the kernel to other OS's (win32) that
would even be neater, I'd love to run a NetBSD session from a win32 dosbox
(yeah, yeah, I know ...). As already mentioned debugging the kernel can
already be done with available tools - still I do see a more 'low granular'
approach to debugging when running the kernel in user space. Education -
maybe a userland kernel would be a nice way for students to start to learn 
how NetBSD (or *nix in general) works. Maybe it can also function as
a easy 'template' for new NetBSD ports ...

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

Hrm, I'm probably lacking in OS knowledge here, isn't stuff like
task switching dependant on a an external (hardware/thread) source.
As far as I know, a callback is hooked on the clock interrupt and
that callback controls things like switching tasks ... no?

One could indeed abstract the clock, but how would the kernel call
it (and this might be the thing I'm missing, the clock is essentially
calling the kernel callback and not the otherway around ... ?) 
 
> > 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.

True - but this would assume the host-OS/kernel would need to support at
least some form of page protection. On SunOS/Solaris one could for
example use a mprotect() call - but if the host-OS doesn't support
something like this it's impossible. Strictly speaking one could 
build a MMU in software but this would be unwise I guess (too slow).
Of course simple allocation calls (malloc()) can be checked but
something like (in userland)

char *foo = (char *)0x12345678;

memset(foo, 0, 0x100);
  
is impossible ... I guess ...

> > 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?

If I understand correctly (but again - I might be missing something
here) - libc is based on the kernel (libc's creat() calls syscall() which
in turn generates interrupt, interrupt gets cought by kernel and kernel
does actual creat() stuff - forgetting about context switching for
the moment) - so libc is based on the kernel and not
the other way around. What I now want to do is base the kernel on
libc (which is the other way around). Hrm thinking about it now,
actually I think I see your point. First build kernel which uses
calls from the host-OS's libc. Then build NetBSD's libc (without the
host-OS's libc interfering).

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

Very true, indeed there will be many problems in various drivers,
NetBSD (like any *nix) requires low-level ethernet/ip/tcp adressing
while a host-OS might not be able to provide that. So I will need
to cut corners here, maybe by partly emulating it. Practically this
means that porting the userland kernel to other *nix's is probably
not too problematic. Any non-posix system will be much more problematic
(but not undoable).

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

Indeed, I've been running Linux for a number of years now but I'm
falling more and more in love with NetBSD.
 
> As someone else said though, why?

It's just plain old fun! ;-)

Cheers,
beez.
 
> -- 
> 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
> 
>