Slashdot Mirror


Bringing xMach To Life

jmallett writes: "xMach, the microkernel BSD Operating System, first made an announcement on Daily DaemonNews stating that there were some new source and binary snapshots available. Also, OsOpinion has an article I wrote about my experiences so far, entitled 'Giving Birth to xMach'. Development of xMach currently is limited to the microkernel and its servers, but a userland (based on that from the good people at OpenBSD) will be worked on shortly. Some of the primary focuses on xMach are data storage, security, and non-bloat."

4 of 77 comments (clear)

  1. Re:xMach should look at Darwin by Kartoffel · · Score: 3
    Darwin may not be ported to x86 yet

    Uhmm.. it sort-of is. Check out darwinos.org, or read Apple's FAQ.

    "Darwin is processor-independent and is built for PowerPC and Intel platforms, enabling Open Source developers to work on Darwin projects on the widest choice of computer systems."

  2. xMach should look at Darwin by sigmond · · Score: 3

    Am I missing something here, or is Darwin already what xMach is trying to be? Darwin may not be ported to x86 yet, but it is the foundation for a comercial product and as such has seen a great deal of development. And if the goal was to create a free implementation of OPENSTEP why not work on porting GNUStep to Darwin?

  3. Re:Mach by bmajik · · Score: 3

    W2k is not based on mach, and the rumours that its stability lessened significantly when win32 and others were allowed to run in kernel mode are unfounded when considered more carefully.

    Give the book "Inside Windows 2000" a read sometime.. but basically, i'll paraphrase

    "Is Windows 2000 Less Stable with Win32 USER and GDI in Kernel Mode ?

    ...the reason the impact on system stability has been minimal is that prior to windows NT 4 (and this si still true today), a bug (such as an access violation) in the usermode Win32 subsystem process (csrss.exe) resulted in a system crash. This crash occures because the parent process of Csrss (the session manager, smss) does a wait operation on the process handle to csrss, and if the wait ever returns, smss crashes the system, because the win32 subsystem process was (and still is) a vital process to the running of the system....

    there is one additional danger that did not exist prior to moving the windowing and graphics system into kernel mode.. because this body of code is now running in kernel mode, a bug (such as the use of a bad pointer) could result in corrupting kernel mode protected data structures..prior to nt4 such references would ahve caused an access violation because kernel mode pages aren't writable from user mode, but a system crash would ahve then resulted, as described earlier.. with the code now in kernel mode, a bad pointer ref that caused a write op to some kernel mode page might not immediately cause a crash, but if it corrupted some data, a crash would likely result soon after..

    .. another area of impact can come from moving the graphics drivers into kernel mode.. previously some portions ran in csrss, and others in kernel mode.. now the entire driver runs in kernel mode..

    ... finally, running the windowing system and graphics drivers in kernel mode is not _fundamentally_ risky... many other device drivers (network cards, hard disk drives) have always run in kernel mode on every version of NT, with a high degree of reliability.."

    his little analysis goes on an on.. talking about the scheduling impact on smp and non-SMP boxes about these moves, and many other cool issues..incase you cant tell i think anyone that uses w2k at all should have this book.. its pretty sweet (and comes with a cd full of neat make-NT-stink-less tools like a self-hosted kernel debugger, etc..)

    its "Inside Microsoft Windows 2000", by Davide Solomon and Mark Russinovich...

    --
    My opinions are my own, and do not necessarily represent those of my employer.
  4. Re:Mach by connorbd · · Score: 3

    WinNT/2K is a joke as far as microkernel design is concerned -- you're right about Microsoft blowing massive holes in the design to do things. They've fixed a lot of that in W2K, but it's still Windows.

    BeOS was a great idea that got bogged down by Jean-Louis Gassee's ego. The fact is that BeOS was "forced" onto Intel hardware because they weren't willing to suck it in and use the information that was already out there in the form of MkLinux (granted that would require some creative interpretations of the GPL, but I'm sure Apple could get away with GPLing Darwin without doing the same to X).

    OS X is very much like what xMach is doing, though it's already been there for maybe ten or twelve years now (or is it longer?). It doesn't have the holes NT has, and it has one of the best object frameworks in the business (even if you do need to know ObjC or Java to use it).

    The Hurd, finally, is not actually vaporware. What it is is a monument to Stallman's hubris in thinking that he could create a cutting-edge OS (and it's bleeding-edge, at the very least, if you know anything about its internals). The problem with the Hurd is that it's an extraordinarily complex piece of software with a limited appeal; where Linux pays little attention to the state of the art and follows the classic Unix philosophy of "just make it work right, dammit", the Hurd from what I've read tries to be the most advanced system out there; almost everything is customizable, and the kernel architecture itself is a Mach-based multiserver. (Read up on it -- you'll grok instantly why it took ten years to get it to daylight in any form at all...)

    There are a few others, I believe. Minix is said to be a microkernel architecture, though I don't know much about it. PalmOS is microkernel-based, but the Palm userland doesn't really pay much attention to it. MacOS uses something called a nanokernel, which I think is nothing more than a very low-level HAL (exactly what use it is I don't know).

    /Brian