xMach is an open source 4.4BSD-like BSD operating system based on the Mach microkernel. Primary focuses are on security, portability, and staying unbloated. xMach work began in November of 1999 by Joseph Mallett, project founder and Core Team Member. In one of my recent stormings to the IRC, I stoped by the #xmach channel and met Joseph. Read more about our brief conversation regarding the xMach operating system.1. I have never used xMach. So, I will need an intro…
Joseph Mallett: Well, it’s closer to 4.4BSD than anything and it’s based around a microkernel but the bsd layer is all the user ever will really notice.
2. So, does xMach have a gui? Does X run on it?
Joseph Mallett: X clients compile and run from xMach but the server itself will not, currently, as far as I know. It should, but nobody’s put in a lot of effort to it…
3. Do you have a “ports” system? Where one can download source that it is guaranteed to compile?
Joseph Mallett: We plan to, however we are still in the process of building a complete native userland and toolchain and such so it’d be kind of silly to be worrying too much about ports yet.
4. How far away from a “1.0” version is xMach?
Joseph Mallett: I’d like to say under a few months, as far as quality goes. However, that’s dependent on developers delivering and me having help with certain things.
5. How many people are contributing code on XMach?
Joseph Mallett: Well, there’s two ways I could answer that, I could tell you how many people have comitted and I could tell you how many committers there are. I’ll give you the “official” answer which is everyone on this page can contribute code to the project.
6. I need the number of people who are commited truly to the project 😉
Joseph Mallett: Basically, everyone except maybe 3-4 people are really attached and devoted in some way or another to the project. I think everyone wants it to succeed and wants to help however they can but they might not have the time or motivation to DO anything but they would if it was more convenient.
7. So, why xMach? Why do you like the project? What are its benefits from, lets say, FreeBSD?
Joseph Mallett: It’s a far more scalable architecture from the ground up, we have facilities like userland pagers and a large portion of things being in user space rather than kernel space. One of the major things this brought about is synchronisation and locking are everywhere because without it, considering context switches can happen at any time and that you can’t rely on the whole system being on one processor or whatever. So it’s very careful about locking and synching.
8. Does XMach support SMP? What is the filesystem used? Other platforms except x86?
Joseph Mallett: SMP support is currently a “work in progress”.
As for filesystems, we only actively support FFS and UFS. There’s support for others in the BSD layer but the microkernel can only initialise a system off UFS or FFS. There are currently ports in progress to sparc64 and macppc but there’s a lot of ports we’d like to see happen.
9. Something else you would like to add?
Joseph Mallett: I’m very pro-security. I’ve sat in xMach all night before and seen how I could lock up the system or destroy various parts and i report it all back in public forums because i care about seeing the system be stable and secure.
10. Is xMach a “usable” system today? Can you do your everyday work with it?
Joseph Mallett: If you’re like me, it is. 😉
Get up to speed with xMach on the IRC server irc.openprojects.net, channel #xmach. Joseph’s nickname is ‘jmallett’.
wow. indepth. entertaining. enlightening. full of facts.
or not.
what are the parallels between xmach and hurd and darwin?
why choose bsd mach over gnu mach?
was L4 or L3 considered?
is it endian and 32/64bit agnostic?
what kind of overhead does xmach have over a traditional monolithic kernel?
will any improvements from CM’s realtime Mach be incorporated?
> what are the parallels between xmach and hurd and darwin?
<p>
xMach is a BSD project, from the license to the servers atop the microkernel, to the userland, to the libraries, etc., and HURD is a GNU project. HURD also has a large focus on being compatible with the current most widely-used GNU kernel, Linux, which means a lot is taken from Linux, such as device drivers. xMach is a community project, people work on it because they want to and it’s fun or personally rewarding to them. Darwin is, of course, not. Also the APSL is a little more restrictive on a license side of things. Also we’re currently much more focused on the x86 platform than Darwin [has been], and we’re actively looking to port to other architectures. We don’t have a product to support with it.
<p>
> why choose bsd mach over gnu mach?
<p>
I don’t quite get what you mean here. There is no ‘bsd mach’. However, in the early days of Mach and BSD, a lot of code was shared between CMU and UCB. Mach itself is very BSDlike in a number of ways, BSD is very Machlike in a number of ways.
<p>
> was L4 or L3 considered?
<p>
Not really. Not in a concious “Gee, should I use L3 or L4 instead?” kind of way. I learned enough about microkernels in general, and tried various pieces of software, and eventually I just said “okay, I like Mach”. In hindsight, the only thing I might have done differently regarding choosing a microkernel to develop on, with what I’ve learned over time, is I might have chosen OSF Mach rather than Mach4.
<p>
> is it endian and 32/64bit agnostic?
<p>
Of course it is, running on an x86. What I mean is that our only finished port is to the x86, and that’s what we have to go by as far as _results_ are concerned. I’ve looked at a lot of the 32/64 issues, and I honestly believe it won’t be any sort of huge problem. However, I’ve been wrong before.
<p>
> what kind of overhead does xmach have over a traditional monolithic kernel?
<p>
To be perfectly honest with you, I haven’t ever bothered to play with that sort of thing.
<p>
> will any improvements from CM[U]’s realtime Mach be incorporated?
<p>
No, CMU *Mach are dead, including their RTMach. However, as it is now, lots has been taken from Keio’s MKNG and the NTT RTMach distribution. I don’t think we’ll ever really get into the realtime stuff though, if that’s what you’re asking. If someone commits it, fine, but personally, I feel “realtime” is very over-rated when it comes to anything but embedded systems. MKNG and NTT RTMach, of course, have lots of other really good stuff too, like much improved driver support, etc.
<p>
Hope I answered your questions well. If you’d like better questions answered, ask for better questions asked. Talk to Eugenia about that.
<p>
<p>
/joseph
I heard something about Mach3, Mach4 and xMach.
I know I’m stupid
, but can somedody please explain the differences between these?
My brain refuses to go into ye olden history mode to answer you really concisely about what Mach is, but…
Mach 2.5: Last monolithic version of Mach produced by CMU. Mach was basically 4BSD (possibly 4.2?) modified for what CMU needed.
Mach 3.0: Microkernel version of Mach
RTMach: CMU’s fork of Mach 3.0 to develop a realtime version of Mach
Mach 3.0 MK84: RTMach merged into Mach 3.0 tree
OSF Mach: OSF’s fork of Mach. Their focus was on compartmentalising _everything_ (among other things)
Mach4: University of Utah’s version of Mach3. Had a standard GNU build format, Linux device drivers, migrating threads, etc.
MKNG: Microkernel Next Generation project headed by Keio university in Japan. Notable features: highly increased [Free]BSD compatability; Ports to other architectures.
NTT RTMach: NTT’s version of MKNG, highly compatible with FreeBSD 2.2/3.x. Includes Lites and some userland stuff.
GNU Mach: GNU’s fork of Mach4. Increased Linux compatability.
OSKit Mach: Utah’s continued work on Mach. DDB, Mach-style drivers, etc., removed. Lots of stuff from Linux.
xMach: Operating system based around Mach4 and Lites, focuses on cleaning up the codebase drastically initially, increasing SMP and related technologies, as well as security (plans to integrate DTOS work as soon as the NSA makes it publicly available, etc.), and portability (incl. not just making the system more portable, but also porting it).
HTH,
/joseph
Thanx
cheers mate. there was some hint of sarcasm in my original comment
those questions i threw from the top of my head.
my understanding (some old faq i remember somewhere) stated gnu mach could not handle smp? whereas the mach4 could? (this is a vague memory….)
and i asked about the hurd parallel as hurd was designed to run under mach kernel. (ergo, mebbe it would run under an xmach server)
are you aiming to streamline xmach as a server for other kernels (ala hurd on mach) or as an entire kernel system (ie: server + device driver level, etc).
whats your relationship with the the net/free/open/trusted teams?
xmach seems like a research project. what benefits do i get from running xmach? instead of freebsd (which i currently run). there need to be some form of gains in order to switch.
is it possible to build a boot machine with xmach using freebsd (4.4) instead of net+openbsd?
is xmach able to build world under its own steam?
do you follow the *bsd style -release,-stable,-current? (i guess looking from the cvs tree, its no?), if no, do you plan on going that way in future?
what kind of support is more required right now?
(more documenters, more coders, more testers?)
whats the top priority for xmach right now?
(cleaner install process? cleanup for 1.0 release
> cheers mate. there was some hint of sarcasm in my original comment
those questions i threw from the top of my head.
> my understanding (some old faq i remember somewhere) stated gnu mach could not handle smp? whereas the mach4 could? (this is a vague memory….)
Mach4 cannot, HURD can via Linux SMP code, as I understand it.
> and i asked about the hurd parallel as hurd was designed to run under mach kernel. (ergo, mebbe it would run under an xmach server)
HURD should run fine on top of xMach’s microkernel.
> are you aiming to streamline xmach as a server for other kernels (ala hurd on mach) or as an entire kernel system (ie: server + device driver level, etc).
Not sure I follow you… We provide a microkernel and [a] server[s].
> whats your relationship with the the net/free/open/trusted teams?
What, as for between projects, officially? I don’t know that there is any. However, I try to keep up to speed on the BSDs in general, as I work with the whole of them quite a lot. There’s a few people from the FreeBSD project who work on xMach, and there’s a few people who are OpenBSD zealots who work on xMach… I wouldn’t say _I_ feel there’s any tension between us and any other BSD, as a project. But that’s just my opinion.
> xmach seems like a research project. what benefits do i get from running xmach? instead of freebsd (which i currently run). there need to be some form of gains in order to switch.
It has an essentially more scalable architecture, it has external (read: userland) pagers [an essential for easy distributed processing], it has quite a bit of synchronisation in it always, as it was designed for SMP and Distributed MP. You can [I hope to improve on this more in the future] upgrade BSD servers without re-initialising hardware (sort of). Eventually, you will be able to start whole new BSD servers inside of a “jail” of sorts, which means you have much more control over the jail than you would in say, FreeBSD.
> is it possible to build a boot machine with xmach using freebsd (4.4) instead of net+openbsd?
Actually, you won’t have any luck with a modern BSD userland, because of incompatabilities with the C runtime objects their binaries are linked with in general. Really, this shouldn’t be hard to work on, and really, we should [read: will] have our own userland anyway.
> is xmach able to build world under its own steam?
It will be able to once a complete userland is added. There is nothing to stop it except developers not importing code.
> do you follow the *bsd style -release,-stable,-current? (i guess looking from the cvs tree, its no?), if no, do you plan on going that way in future?
We follow a RELEASE/STABLE/CURRENT pattern. The current -rHEAD is 0.1-CURRENT. There is no RELEASE or STABLE branch at the present time.
> what kind of support is more required right now?
> (more documenters, more coders, more testers?)
Coders, Documenters, Testers. In that order.
> whats the top priority for xmach right now?
> cleaner install process? cleanup for 1.0 release
complete userland, installer, smp, more drivers. In that order. Of course, I’m working on the last one currently, which doesn’t make much sense, but that’s how I am. I jump around as to what task I’m doing… Like, if you’re holding a large item mostly by yourself, you may have to shift positions to keep from wearing yourself out and dropping it completely.
>wow. indepth. entertaining. enlightening. full of facts. or not
As I say in the article, this is a MINI interview (barely an INTRODUCTORY to the project), and it was made through an IRC chat. It was not meant to blow up your mind.
Great job Eugenia. Keep up the great work.
-Jason “Maverick” VanDerMark
Congratulations jo.
I anticipate xMach 1.0