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.
Post a Comment
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
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
