Date: Thu, 30 Jun 2005 13:55:03 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: DANIEL hoggan <danny280279@hotmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: mach microkernel Message-ID: <20050630134655.A87930@fledge.watson.org> In-Reply-To: <BAY104-F275CC7096CEA413501CB95B5E00@phx.gbl> References: <BAY104-F275CC7096CEA413501CB95B5E00@phx.gbl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050630134655.A87930>