[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arch
Subject:    Re: mach microkernel
From:       Robert Watson <rwatson () freebsd ! org>
Date:       2005-06-30 12:55:03
Message-ID: 20050630134655.A87930 () fledge ! watson ! org
[Download RAW message or body]


On Wed, 29 Jun 2005, DANIEL hoggan wrote:

> I am using mach4 as my os for my project i just wanted to know, if mach 
> uses a lot of bsd code to emulate unix funcionality, then would porting 
> bsd code be a simple case of just dropping it in, or does it actually 
> require some rewrite, i mean according to the mach4 page netbsd is 
> capbable of just dropping in mach4 microkernel:
>
> http://www.cs.utah.edu/flux/mach4/html/projects.html
>
> Easy-to-install Mach distribution:  In order to attract more people from 
> the Linux/BSD crowd, we really need someone to put together an 
> easy-to-install Mach+Lites or (when it's mature enough) Mach+Hurd binary 
> distribution. This distribution might be just an add-on supplement to an 
> existing monolithic-kernel distribution, or it could be an entirely 
> separate distribution with a whole new set of binaries. Of course, a 
> simple add-on to an existing distribution is likely to be simpler and 
> more popular, so we should try to go with that approach if at all 
> possible. (Mach+Lites on the i386 is already pretty close to being a 
> drop-in NetBSD kernel replacement.)

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.

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

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

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.

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.

Robert N M Watson
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]