Slashdot Mirror
xMach Announces Core Team
Joseph Mallett writes "xMach today announces our brand new Core Team. We've also (finally) added a CVS server, as well as a CVSweb front-end so people can browse the source. Since the first Slashdot post, we've accomplished one of our major goals of being GPL-free (and thus fully BSD License'd), as well as added two mailing lists and fixed the wishlist code. Due to Mach's history with Multiprocessing, we are currently looking more and more and the ideas of distributed processing. The code base is now cleaned up, so that everything should compile out of box. Some of our more abitious goals are to move to a multiserver format, and do a major update of the filesystem interfaces, short term. And like the HURD, it's software that's here right now, and isn't vapourware."
I'm not a kernel guru, but I've made the following observations while I was working with MkLinux (so all comments relate to that version of MACH):
- Mach is rather bloated. The Mach kernel was significantly larger than the Linux server, which IMHO tells a lot.
- Mach has evolved into a giant patchwork. The source code is FULL of (years old) comments like "XXX THIS REALLY NEEDS TO BE FIXED !!! XXX". In general, the code is messy, to say the least.
- Some internal MACH interfaces are definitely not well-thought out. As an example, reading from a block device required to send a message first to set the block number, and then another message to initiate the read. Apart from this uneccessary overhead, the device driver thus needs to maintain more state which inhibits any possible parallelism.
Mach has some nice ideas, but IMHO it needs to be rewritten from scratch - right now, this "micro"kernel is carrying around much more historical baggage than some monolithic kernels, thus skillfully combining the disadvantages of both monolithic and microkernels while avoiding most benefits of any of them.
- A.P.
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I believe your interpretation of the GPL is incorrect. The person sharing code does not expect any direct return (through money or credit) from their code.
GPL = Kid who shares his toys with goodwill, and says that anyone who wants to use the toy must share their toys as well.
And Direct-X!
"The original L4 -kernel for x86 has some shortcomings which we intend to fix with this new implementation. The Fiasco kernel:
See also the L4Linux project:
"L4Linux is a port of the Linux kernel to the L4/x86 and Fiasco -kernels (microkernels), two kernels implementing the L4 -kernel API."
"L4Linux runs in user-mode on top of the -kernel, side-by-side with other -kernel applications such as real-time components. It is binary-compatible with the normal Linux/x86 kernel and can be used with any PC-based Linux distribution."
--
rant
It's like the motto "live free or die". What if I don't want to live free? Does it mean I don't have the freedom to decide not to live free - and am therefore being not free to decide whether or not to live free.
Ow, my head hurts...
Ita erat quando hic adveni.
The (unfinished) goal of the GNU Project was to create an operating system with no proprietary software in it. Why? Because they didn't want the restrictions of proprietary licenses. What a worthy goal!
But for some people, the restrictions in the GPL are still too much. It's much, much better than proprietary licenses, but it still has restrictions on distributions. The xMach team wants to create an operating system with only copycenter/unrestricted software. What a worthy goal!
'There was a village that had a magical apple tree. Whenever an apple was picked from the tree, another would replace it. The villagers were well fed and had no want. But some villagers took their apples and locked them away, saying "Look at those foolish people! They do not lock away their apples. Surely someone will come and steal them."'
A Government Is a Body of People, Usually Notably Ungoverned
In this case, it is the *user* who decides which version to distribute the software under, not the author. If the GPLv3 is too restrictive (and parts of it sounds like it might), then you can still keep distributing the software under GPLv2 instead.
A Government Is a Body of People, Usually Notably Ungoverned
In a nutshell, yes...
You are not free if you do not have the choice to be free or unfree. And if you have the ability to choose unfreeness, then you are free. Even if there is no turning back on unfreeness, at least you were free at the time you made that choice.
This is in stark contrast to proprietary software. You are born free and then subsequently choose to use proprietary software. If you don't like it, stop using it. It's like walking into a closet and shutting the door behind you. Your movement is now restricted because you are in a closet, but you are still free and the closet is not subjugating. Just step out! People *choose* to use Linux or BSD instead of Windows. How can they possibly be unfree if they have that choice?
A Government Is a Body of People, Usually Notably Ungoverned
Note that it states that the file is GPLed, with no mention of the BSD license or, in fact, of the BSD copyright ("original taken from" is not a copyright notice that I'm familiar with). I assume that they got permission to do this, or the the file was public-domain, especially since (I'm almost certain) 1993 pre-dates the removal of the advertising clause in the BSDL, which might have been sufficient reason to avoid using the file altogether. I can really see them stealing the header and leaving attribution, either.
copy on write and signals have nothing to do with each other
In mach, they most certainly do. There are a number of resources that are difficult to copy-on-write because they are too high-level to be managed by the VM. With mach's copy-on-write semantics, you can actually manage the copy in a user-space callback.
message passing ipc is more expensive than just invoking a user space signal handler
Expensive yes, but much richer. Sending a SIGFIZZ to the process is all well and good, but in most cases, the process then needs to go dip into some kernel datastructure or make a system call to get more information. With message passing, you get it all in one pass, and you can define richer message classes than the traditional POSIXish signal mechanism can deal with.
the whole point of a microkernel is to have a different fault domain for each subsystem
This is actually a kind of funny statement. Since microkernels are being used most often because they provide a conviniently small and flexible abstraction layer for monolithic operating systems, I think you have to revise your thinking here. Perhaps when microkernels were envisioned this was the idea, but throughout the late '90s and early '00s, we've certainly seen very little of this sort of microkernel use.
This use of microkernels is not invalid, nor is it rare. Would all monolithic OSes benefit from a microkernel-as-abstraction-layer? Yes I think so in the ideal, however many OSes (e.g. Linux) have seen tremendous benefit from the monolithic model that they started with, and to re-impliment on top of, e.g., mach, would be quite painful. I'm not convinced that the benefits would outweigh the cost.
Linux (or FreeBSD or MacOS X, etc) is UNIX is 1960s technology in the same way that 2000 is NT is VMS is 1960s technology.
;-)
Neither one is a very fair statement, since development has progressed dramatically (including at least one major re-implementation along the way) in both cases.
Oh well, trolls can't be right all the time
NT has no relation (other than conceptual) to Mach. MacOS X, NeXT OS and OSF/1 (from which True64 descends) are all Mach with some relatively monolithic layers on top.
;-)
It is important to note that those three systems are monolithic systems running on top of a Mach microkernel. Mach has not, in any of those cases, been modified to the extent that it no longer functions as a true microkernel.
Also, the original post made no such distinction. It made a blanket statement that Mach had never been used in a production OS. This is untrue, and there is a fair deal of advantage in having the microkernel abstraction available, even if you run a monolithic kernel layer on top of it.
For example, take the fact that OSF/1 based systems use Mach message passing and VM, so they can handle such fun concepts as reserve-on-write memory allocation with message-callbacks on failure. In UNIX terms, that means that "malloc(1024*1024*1024)" does not reduce the amount of VM available... which is both scary and useful at the same time
The proliferation of copy-on-write semantics in Mach-derived systems is also very useful, and again benefits greatly from the way mach does message-passing instead just having signals to convey information from the kernel to user space.
You'll have to define "successfully," then. Notwithstanding your criticisms of Apple's business models, MacOS X has sold as many copies in its initial week of issue as there exist estimated users of most free distros of BSD-based UNIX systems.
BTW - Mach has done more to stiffle microkernels than any theory or performance debate has ever.
No more than COBOL, FORTRAN or BASIC stifled programming languages. In this community, such debates are won on the merits.
To most people microkernel == Mach (which has never been used successfully in a production system)
MacOS X?
Darwin isn't licensed under BSD. Reasonable people might prefer BSD to ASPL
we should be using microkernels, however every time someone tries to make a microkernel they give up and go grab the source for mach which just sux ass hardcore.
How we know is more important than what we know.
see that's the problem. people like you just quote the microsoft propoganda without actually knowing what this "technology" is that they are talking about. Here's a hint: it involves microkernels vs monolithic kernels. Try thinking for yourself, I know it hurts but you might learn something.
How we know is more important than what we know.
ok, let's concede that one.. does this change my point at all? If people didn't constantly try to base their microkernels on Mach we would have some sort of progress and not still be using monolithic kernels.
How we know is more important than what we know.
that's amuzing because I just used it and it conveyed meaning to pretty much everyone who read it. That qualifies as a "word" in my book. So perhaps what you ment to say is that I misspelt it and as such I would remind you that I never said anything about the front page story's spelling. So shut the fuck up ok?
How we know is more important than what we know.
and the gui, let's not forget the gui. My only point is that people should actually reimplement rather than use Mach which is such a lame first generation microkernel.
How we know is more important than what we know.
and != at && like != unlike
try putting in a tiny bit of effort so thousands of people the world around dont have to. BTW - Mach has done more to stiffle microkernels than any theory or performance debate has ever. To most people microkernel == Mach (which has never been used successfully in a production system) or WinNT which just blows. No wonder we're still using monolythic kernels in the year 2001.
How we know is more important than what we know.
What is it with you *BSD haters out there? I mean, jesus. I keep seeing this same rant, posted almost verbatim, anytime there is an article about one of the BSD's. BSD is not dead, it will not die, it happens to be thriving.
Also, claims of fragmentation in the BSD community are completely bogus. The seperate BSD operating systems are closer in operation than half of the Linux Distributions. OpenBSD is closer to FreeBSD than Slackware is to Debian. If you do not believe that then you have not run them.
The different BSD's are distinct operating systems, like Solaris or HP/UX. They are not fragmented distributions. The Linux world is the fragmented one. There are some 180 linux distributions according to the LDL. Even if only the top 20 or so are reasonably large, that is still a far larger number of distributions than in the BSD camp. And as I already pointed out, half the time the Linux distributions are incompatible with each other, despite being the same OS! (By incompatible I mean that either there are inane library problems (glibc, etc) or they are completely different administratively.)
Do everyone here a favor and go troll somewhere else.
-sirket
I'll give you 50 cents, go buy yourself a clue. Darwin is aimed at being a rock-solid core for the new MacOS-X system, and being similar to the core of NeXTStep. xMach is aimed at being small, thin, fast, and clean. While Darwin is based on old FreeBSD 3.2 code, xMach aims to be as modern as possible (and according to the story, the site is down) will try to take advantage of some of the latent features of the Mach kernel, such as fine grained locking for multiprocessing, that have been neglected in recent BSD releases. (Read the UVM design thesis for a description of this, FYI)
A deep unwavering belief is a sure sign you're missing something...
Just to elaborate on his point. Mach really *is* giving microkernels a bad name. Two of the fastest UNIX-compatible systems (BeOS and QNX) are microkernel based. Yet, since everyone sees Mach as representing microkernels in general, people automatically get the idea that microkernels are slow. Just to give you an idea of the situation, its like everyone saying Linux is slow, because Win95 sucks and both use a monolithic kernel.
BTW> I was thinking. From looking at the Win95 design, it seems to me that Win95 may just be the most "advanced" of any commerical OS design. Since most Windows95 components are user-level libraries mapped into each program's address space, it would seem that Win95 is the original exokernel!
A deep unwavering belief is a sure sign you're missing something...
http://www.benews.com/cgi-bin/mwf/topic_show.pl?i
John has told me that he would fix it, and even today that he has fixed it, but beats me where the new binary is! :)
The moral of the story is, regardless of what license you choose, some people will try to rip you off anyway. So there's no point in further discouraging legitimate developers, who could possibly give back in the future, with a license that binds their soul to the project.
-bugg
I worked for a company that sold super-computers running a mach-based OS. That company has since been purchased by HP and the mach-os was dumped as quickly as possible.
As I recall, there were two really major problems with mach:
1) Buggy as all get out
2) Enormous message-passing latencies. System calls that take a couple of microseconds under HPUX took 100s of microseconds under mach on the same hardware.
When information is power, privacy is freedom.
L4
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
search the l-k list archives for some examples. one point is that only one thread at a time can be in any module, as a result of messages being queued. mach is much slower than other microkernels when it comes to message passing. another issue is that when you shove use a monolithic unix server (eg, as do mklinux, bsd lites, next), you lose all the advantage of using a microkernel in the first place. if your single server dies, everthing's shot anyway. also, message passing is not the only way to isolate fault domains. (see here.)
i don't believe that message passing really gains you much abstration. if you had all the vm calls/messages placed in a generic way, it wouldn't let you optimize for the specific pager implementation. but, to allow an easy drop in replacement, you wouldn't be able to depend on the current vm's subtle behaviors. this is just my thought; i haven't exactly done a lot of kernel design, so take that with a grain of salt.
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true?
yes, it's definetly true. i know the mklinux server has been debugged using another running instance of the linux server. people have often talked about run time switching between mac os x and mklinux, but nothing's come of it. and to be safe, it would need some resource locking, eg, so that you don't have the two servers writing to the same disk partition.
"I may not have morals, but I have standards."
"I may not have morals, but I have standards."
That's actually not true. L4 is GPL, and highly regarded. HURD will probably be ported to it soon, with a great performance increase.
"That old saw about the early bird just goes to show that the worm should have stayed in bed."
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I don't know enough of the Mach internals to know exactly why it's such a poor performer, but I have read alot of theories put forth. The most common(and accepted) reason is that Mach's memory management is too abstract and that because Mach is built on a hardware abstraction layer. Those two reasons are directly interrelated.
The Hardware abstraction layer(HAL) restricts the u-kernel to operation on a "generic machine". Everything is abstracted in the sense that the HAL contains the units which are common to all CPU architectures. This was done to improve portability. However, it sacrifices a great deal of performance because alot of issues are platform dependent. Things such as page size must be dictated by the architecture you are running on. But because Mach uses the HAL to abstract this away, Mach performance suffers a great deal in memory operations. Often, the HAL dictates a page size which is too small/large for the architecture. The hardware can't handle address translation anymore, so the kernel has to do this manually. This is very expensive.
In general, Mach's architecture just seems poorly designed from what I've read. Alot of research has been done on this topic, and they're coming to the realization that u-kernels are inherently non-portable. That's a very important point. This shouldn't be surprising either because the u-kernel is so small that mostly only platform dependent code end up in there. L4 is 12k, Eros is 32k(I think), VSTa is around 50k and QNX is less than 10k!
The good thing about this approach is that most(if not all) of the platform-dependent code is wrapped up in the u-kernel. The rest of the system is completely portable. So all you have to do is re-write about half of a 20k kernel for the new architecture, and you're done! Re-compile and off you go. Theoretically at least.
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Good u-kernels that have implementations with performance comparable to or exceeding Linux:
- QNX: Everyone's heard of this one. They have a very good u-kernel.
- Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
- Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
- VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
- Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).
Helpful note: if I've listed a website to a university site or academic operating system/kernel, the documentation easiest to skim is found in the papers they've published.If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
I have no idea. Ignorance of their existence probably.
Unless i am quite confused, supposedly, because the interaction between the microkernel and the OS is somewhat abstract, you ought to be able to replace the microkernel with a better one as long as the interface is the same. Is there any reason a better microkernel with the same software-side interface as Mach could not be written, and used to replace mach?
Yes you could. But then you'd just have Mach.
someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
Yes that's true, but not in the way you're thinking. Both kernels don't run as kernels at the same time. A well-engineered u-kernel is so thin and provides such a minimal interface to the hardware, that by just slightly modifying Linux(or other kernel) you can get it to run on top of the u-kernel like any other application, and it could do everything that Linux does running on the bare hardware. See L4Linux, MkLinux, Darwin/MacOS X and even this xMach project as examples. The key to good performance is to provide as small a u-kernel with as minimal an interface as feasible to avoid performance problems. It will never run as fast as on bare hardware, but you can get pretty damn close.
I am just thinking that at this point, it would be an utterly useless but nifty parlor trick to try to get Mac OS X/Darwin, MkLinux, xMach and HURD running off the same mach microkernel on the same machine at the same time.
Not so useless as you might think. The problem with any new operating system or kernel is software. There's nothing written for it yet. But what if you could run the Linux kernel on top of your new OS? You'd have near instant access to whatever drivers and applications are currently available for Linux without any porting effort! (except for the initial Linux port) Then you can have a complete system and start writing native drivers for what you need.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
To have fun and to meet likeminded people who all think they can contribute together to do something worthwile!
After reading Carnage4Life's excellent post, you might also want to dig up the papers about Spring from SunLabs. Spring wasn't just a microkernel; it was a complete multi-server OS with some neat features like Plan 9-style extensible namespaces and single-system-image clustering.
Hopefully the folks that run xmach.org will move it to a more reliable OS (perhaps like that evil GPL one) given the status of http://www.xmach.org... :)
"Population 1,656"
Since when? I would think it would be more accurate to state that most of the license snobs here on /. think that any license should meet the OSI standards but also should be defended. The reason you here so much more about the GPL is that it is *hard* to violate the BSD license. Many think this is a good thing and in fact I'm starting to think somewhat that way myself. I have real problems with version 3 of the GPL and pray to gawd that nobody adopts it.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
As to why (so termed) 1st generation microkernels are still used as the base for newer systems, I can only speculate - but I believe that tradition is the main reason here (teaching an old dog new tricks tend to be hard). Just for the record, however, there is actually an effort to port it to L4.
For more info on L4 related issues, you could have a look at L4Ka, a C++ish implementation of the L4 API.
Bad news. Officially, MacOS X is "MacOS X 10.0". Future versions will be numbered "MacOS X x.y" and so on.
The idea is to distinguish it from MacOS Classic which isn't going away for a while. Too bad - I was hoping for a MacOS XI.II some day.
Unsettling MOTD at my ISP.
The current person cannot remove or change the license. This does provide the greatest freedom for the next person to receive the code, because we are not asking any more of them than that they acknowledge that we wrote the code.
GPL = Kid who shares his toys but expects a return if the person enjoys it and makes it better. BSD = kid who gives his toys to the Goodwill and hopes that someone will find them useful, without demanding or expecting anything in return.
---
"Do not meddle in the affairs of sysadmins,
---
"Do not meddle in the affairs of sysadmins,
for they are subtle and quick to anger."
Haven't we all already adopted it?
Most (all?) GPL code says somethig to the effect of "This is licensed under GPL 2.2 or later"
Ryan T. Sammartino
Ryan T. Sammartino
"Ancora imparo"
It's great to know that no one in the GPL community has ever bashed the BSD license. That's so righteous of you guys. We should follow your example.
However, the xMach guys are not bashing the GPL. They are merely not desiring to use it. Can't you see the difference? Are you offended that "freedom" means that people don't have to make the same choices as you?
A Government Is a Body of People, Usually Notably Ungoverned
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea?
Gladly. And I don't even have to do it myself.
For starters, check out On u-Kernel Construction, a paper written by Jochen Liedke for the 15th ACM Symposium on Operating System Principles. It contains a thorough technical explanation of why Mach performs poorly, and provides corroborating evidence measured on multiple architectures.
Additionally, using Mach as a "hardware abstraction layer" for a userspace Unix server, rather than as a true microkernel, only compounds the kernel and related subsystems' poor performance.
I would like to clarify to everyone that the site isn't in fact down, nor is any server related to the site. What happened is my DNS servers (which are on Verizon internet) became unreachable _NOT_ because of Slashdot, but because _my DSL is down_. To clarify, the site is hosted on soem rather fat pipes, not hosted by me. One mirror runs RedHat Linux, the other runs FreeBSD. They are both up and running. If you want to view the Core Team page complete with everyone's picture on the Canadian server, try http://www.velocet.ca/~smegsite/xmach/core.html , if you want to view the entire webpage, which is a few hours out of date, try http://xMach.FreeOS.com. Thanks. And to clarify one more thing, Mach Mach3 was monolithic, so all of you people talking about a lot of Mach 2.5 derivitives being exactly the same, you're wrong. And yes there have been a number of 'production' oses based on a microkernel Mach. Unicos comes to mind.
--
Someone made a statement along these lines (Microkernels are a good idea but Mach is a poor implementation of the idea of a microkernel) earlier, in the slashdot discussion on the kernel of Mac OS X and Linus' long-standing dislike for microkernels. Like you, they failed to back this assertion up with anything at all.
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there? If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels
Past that: Unless i am quite confused, supposedly, because the interaction between the microkernel and the OS is somewhat abstract, you ought to be able to replace the microkernel with a better one as long as the interface is the same. Is there any reason a better microkernel with the same software-side interface as Mach could not be written, and used to replace mach?
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
I am just thinking that at this point, it would be an utterly useless but nifty parlor trick to try to get Mac OS X/Darwin, MkLinux, xMach and HURD running off the same mach microkernel on the same machine at the same time.
Thanx0r. I look forward to reading the xMach web page and finding out what it is as soon as their web provider recovers.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
It seems you are refering to this post of mine a while ago. For proof of Mach's deficiencies I linked to two research papers; On Microkernel Construction and The Impact of Operating System Structure on Memory System Performance in that post. If you want the capsule summary then here's a short list of Mach's deficiencies as posed by Liedtke
- Inefficient kernel-user switching (i.e. system calls spend too much unecessary time in the kernel).
- Inefficient address switching (i.e. the number of cache and TLB misses in the Mach microkernel is also absurdly large).
- The performance of IPC operations and thread switching is subpar. (this is related to the above points).
- It isn't optimized for specific hardware and instead has a Hardware Abstraction Layer which slows it down considerably.
The paper is a few years old so the Mach people may have tackled some of these problems by now.If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Neutrino and EROS to name two.
If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
The same reason most of us are using Java and C++ instead of SmallTalk, Lisp or Objective-C. Developer inertia and people falling to the more hyped and/or better sold technology.
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
A microkernel can load different modules at runtime that may be OS emulation layers that mimic the behaviors of certain OSes even down to memory management and paging. Since you can theroetically load as many modules as you want, you can load various emulation layers and mimic several OSes at once. For instance OS X has a microkernel that loads modules to mimic BSD as well as old Apple APIs (Classic) as well as teh new stuff (Carbon). Here's a graphical look at how the MacOS X architecture.
--