Date: Fri, 01 Jul 2005 00:13:35 +0000 From: "DANIEL hoggan" <danny280279@hotmail.com> To: freebsd-arch@freebsd.org Subject: Re: mach microkernel Message-ID: <BAY104-F17E847E73A7717FB501A6CB5E20@phx.gbl>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. ------=_NextPart_000_5aab_cbc_6d9e Content-Type: text/plain; format=flowed >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@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters ------=_NextPart_000_5aab_cbc_6d9e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BAY104-F17E847E73A7717FB501A6CB5E20>