mach microkernel

[DANIEL hoggan]

>I'm not specifically familiar with Mach4, but the blending of Mach and BSD 
>is non-trivial in several areas:
>
>(1) BSD processes are layered on top of Mach tasks.  In the new world 
>order, threads are also important, so you'd want to layer BSD threads on 
>top of Mach threads.  there's a bunch of important-to-get-right stuff here, 
>including synchronizing between the micro-kernel task state and the UNIX 
>server process state, which grows more complicated if you're using a mature 
>multi-thread/multi-processor BSD kernel (such as FreeBSD), but maybe easier 
>with a Giant-locked kernel (NetBSD).
>    Another interesting area here is the handling of asynchronous traps and 
>signals.  And another interesting area is debugging.
>
I want to put most of this code into user space, I'm not so much worried 
about actually replacing the BSD kernel, I want to use the code on top of 
the mach kernel, ie Mach would be the actual OS, If I could use the Mach 
Kernel in the same way as NeXt did when they created Nextstep then I would 
have achieved my goal, similarities can be drawn between the way Rocklyte 
systems created their Athenyx OS out of Linux.

Have you heard of Mach-US it was the Multiserver OS created out of the Mach 
microkernel, anyway this project has gone the way that old things go, So I 
basically wanted to know if I could rip out the guts of the BSD code-base, 
you know Mach4 microkernel, ufs, debians autoinstallation and dpkg code, 
drivers based upon the opendarwin codebase and their documentation (mainly 
documentation), and fill in the gaps in the code with the BSD code base?  
Now would it be possible to do this?

>(2) NetBSD also used a Mach-derived VM model, but as with everyone else, 
>has gone their own way on merging their VM and buffer cache.  In 
>traditional Mach, the VM primitives are provided by the micro-kernel, but 
>higher level VFS concepts are implemented in the BSD server, in particular, 
>vnode pagers, etc.  The merging of Mach and BSD here is highly non-trivial, 
>and basically involves throwing away the BSD side VM stuff, and then 
>re-merging the BSD VFS with Mach VM.
>
>(3) Device drivers.  Of particular importance here is that BSD device 
>drivers assume they're running in ring 0, although with
>     busspace/busdma, it's easier to indirect.  You'll need to decide what 
>functionality will go where.  You may want device drivers to run in the BSD 
>server, due to integration with the BSD ifnet, storage, etc, concepts.  On 
>the other hand, it's hard for a micro-kernel to
>     bootstrap without access to storage...

Storage would be implemented by UFS being written to Mach itself.
>
>(4) Once you have BSD running on top of Mach, you'll observe there are some 
>significant redundancies between Mach and BSD.  For example, shared memory 
>and synchronization primitives for applications.  Apple has chosen to 
>implement some of these primitives wrapped around Mach primitives, such as 
>semaphores in Mach.  Others, they have redundant implementations due to 
>semantic differences that are harder to paper over.

I really wouldn't be papering over anything, I'd be totally rewriting so 
that Mach would be the operative kernel source.

>You'll probably also need to think hard about things like kernel linking, 
>kernel modules, kernel debuggers, and so on.  So I'd say "drop in" is 
>probably a bit off-the-mark.  However, it's probably true that you could 
>update a number of the BSD components in Lites fairly easily, especially if 
>you already understand the changes going on in BSD over the last ten years.
>
And if I don't?  Could I try to link the modules, debuggers, directly to 
Mach or would that be asking too much?

>An interesting reference here is Apple's Darwin work.  While they run the 
>whole kernel in a single address space, they have maintained a code-wise 
>separation and layering between the Mach pieces and the BSD pieces.  This 
>falls apart if you look closely, due to assumptions about vnode pointers 
>and ports, in the device driver code, etc, but still shows a lot of the 
>important points.
>
Here I really would Like to implement them in Mach space, I'm wanting the 
kernel small for a reason.  I want it to be elegent, and simple to maintain, 
I don't wan't a monolithic design if I can get away with it. If I have to 
port it all over to Mach then I will, can that be done?  I wouldn't be using 
bsd's drivers, I'd be using Apples.  I would be using ufs (albeit with as 
much as I could manage to implement of the idea of recording data so that 
you actually didn't have to save your work, It's supposed to work in the 
sameway that you remember things but none of the functionality of that is 
available at this moment so basically I've got to stick with just being able 
to autosave data through a recording mechanism.) and probably adding in some 
of BSD server code as libs running on top of Mach, does any of this make 
sense, It would be based on the BSD code-base but not the BSD kernel if you 
see what I mean, the debugging devices, the kernel modules would be 
implemented as componants of user-space.



>_______________________________________________
>freebsd-arch at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters