Slashdot Mirror
Get To Know Mach, the Kernel of Mac OS X
An anonymous reader writes "Linux is a kernel, not an operating system. So what is Mac OS X's kernel? The Mach microkernel. The debate around Monolithic (Linux) and Micro (Mach) kernels continues, and there is a great chapter online about the Mach system from the very good book 'Operating System Concepts'. Which design is better? I report, you decide." Warning: link is to a PDF.
The apple metrosexuals vs the greasy bearded GNU/linux hippies! Who will win!
commence the dead horse beating. i start : mach owns.
So people can do the
You got a light Mac?
No, but I've got dark brown NeXT machine.
joke.
Huge PDF on Slashdot. This can't end well. Mirror
This appendix on Mach is from the newest edition of the classic "Operating System Concepts," Seventh Edition by Silberschatz, Galvin, and Gagne (Wiley). ISBN: 0-471-69466-5. Published December 2004.
/. them): http://www.wiley.com/WileyCDA/WileyTitle/productCd -0471694665.html
There are also free online chapters for FreeBSD and Nachos.
Link to Wiley's purchase page (given that we are
The modular design of microkernels makes for easier design & debugging, and with some designs the freedom to make user space services that can only be in privileged space in monolithic designs, but does one want to pay the overhead for all that message passing? Now that we are getting into parallel processing at the consumer level with multicore and hyperthreaded chips, maybe the answer is yes.
Warning: link is to a PDF"
Um, if you want to warn anyone maybe you should warn the sys admin of the server that hosts the PDF file that you just put a link to on the main page of slashdot. I think they'll care a little more about the super slashdot effect (I'm coining that term for when a non-html file is linked to from slashdot - be it pdf, mpg, avi, etc.) than we will about taking the extra time to load.
... benefits and detriments exist for both monolithic and micro flavors. I doubt a conclusion could ever be made about which one is 'better'... because it all depends on context. "How will the system be used?" "What kind of environment will the system be operating under?" "What are the performance goals of the system?" "What types of hardware will the system(s) need to support?"
Each system has benefits... but they almost always rely on the existence of certain assumptions.
Let's ask what OS is better. The Apple and Linux people will go at each others throats and will in the end agree that they hate Window$.
Smucks.
This is another way of starting a sig with this and ending it with that.
I thought the article was more than relativly informative. Personally I love my mac and I think it's about time people stop fighting over which OS is better, use the right tool for the job, be that Linux, mac, windows, whatever. Anyways, figured I'd throw in a link to some other cool stuff about mach. http://rentzsch.com/papers/overridingMacOSX The page deals with code injection and function overriding within MAC OS X. I think something like it was on here not too long ago but it's also pretty interesting stuff, I'd suggest the read.
So, even though it uses Mach, you can't call it a Microkernel.
Monolithic translates to no modules, correct?
I can't believe people are modding you up for this.
The Linux kernel is monolithic. Linux modules do not run in user-mode. They are loaded into the kernel proper.
mkLinux was an Apple-sponsored effort to run Linux on Mach. The Linux kernel was modified to run in user-mode; it basically became an executable. In fact, you could run multiple instances of the same kernel (or different kernels) simultaneously.
-mkb
That is monolithic as well, but not using the term in the same way. Monolithic essentially means made from a single piece. This CAN refer to modules as well, as the kernel modules aren't built into the kernel binary, but in the case of monolithic vs. microkernel, it doesn't refer to how the kernel is built. Rather it refers to the execution of the operating system kernel. A modular Linux kernel loads as a single executable that then loads modules into it's process space as needed to do things. This is essentially a monolithic kernel. The OS runs as a single process. Microkernel's have the OS split as seperate processes, mostly outside the core microkernel (which has the job of facilitating message passing between all these processes, and lowlevel process management). The Microkernel may or may not do I/O, sometimes seperate processes do. Hope that helps.
Linux is a kernel, not an operating system.
Google's definition of Linux
I think you have more of a chance to start a discussion on that statement then you do in regards to which kernel is "better".
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
So if linux adds new capability than you should be able to just add that subroutine in the a directory and it just works. Well nope. You have to compile the entire kenrel to get new features.
If only they posted on /.
GNAA-tastic.
Brain(s): 0.0% user, 1.3% system, 0.1% nice, 98.6% idle
> Maybe I'm mixing terms here, but I was under the impression
> that linux is NOT monolithic - its quite modular. Monolithic
> translates to no modules, correct?
No: Both the modules and the rest of the kernel run in the same address space, so Linux is monolithic.
A microkernel approach puts some (most, for second-generation microkernels like L4) traditional kernel features into user space, where they cannot hurt the kernel directly, by overwriting memory.
*Commence horrible flashback to "OS Design" class as an undergrad*...
With the first link, the chain is forged.
stop spreading the myth that Xnu is a microkernel
Although the Linux kernel now supports modules, there are a lot of features traditionally built-in that really should be split off. I mean, really, do the schedualler, line cache, and sphygmometer need to be built into the kernel?!!!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
So... does anyone here know what Steve Jobs and Mach have been up to since their halcyon days at NeXT?
Well nope. You can insert newly compiled modules into a previously compiled kernel to get new features (that's how the many proprietory video drivers work, for example.) But those are
a) running in kernel space, not user space
b) communicated with by predefined hooks, rather than a generic message passing interfacing.
That's why linux modules, which are superficially like elements of a microkernel, are not really like them at all.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
I could be wrong, and I'm sure I'll be told if I am...but the issue is related to what happens at compilation and runtime. In most instances the Linux kernel with the exception of items setup and KLMs are built into a single monolithic kernel, all drivers and kernel related items are in one system. There is no dynamic loading and unloading under this model. But in the case of Mach and even the rest of the OS X system everything that can be put off till later usually is by only loading what is immediately necessary. The kernel is a small item which loads everything else as it needs it instead of being built with everything it may need at compile time.
Mach pushes decisions about what it needs off until runtime instead of compile time and this translates into smaller footprints and quicker startup in most cases. Whereas linux only makes limited use of KLMs and that means most decisions have to be made at build-time and is not put off.
Firefox has an extension for PDF Downloading which gives you the option to download a pdf link, in case opening pdfs in browsers bothers anyone.
PDF Download
No, Linux is monolithic by design, with the option to use modules. Monolithic does not necessarily translate to no modules. It refers mainly to the underlying design of the kernel.
Linux is not 100% monolithic, it does use modules, so it's more like 99% monolithic. The main difference between a microkernel and a monolithic kernel is that the microkernel runs most things in userspace, which is more safe and more interchangeable, but generally thought to be less efficient.
Basically the microkernel is the most beautiful design, I don't think anyone could disagree with that. But a monolithic kernel gets the job done, so it's not like it's bad either.
The apple design is, however, what i'd call bad. They've taken a microkernel (Mach), and implemented a monolithic kernel beneath it, to run their legacy apps!!! It's ugly!
Not the way the term is used in computer science, it's not enough to have a modular design or loadable modules for device drivers, but to have a small core that abstracts OS services in an OS agnostic way to higher layers, and that loads the higher layers as needed.
"The debate around Monolithic (Linux) and Micro (Mach) kernels continues..."
There is no debate. It has been well accepted that micro-kernels are the way to go.
--
Toby
monolithic in this case also means interface-monolithic.
basically all the interfaces are defined as symbols to the linker, and all interfaces are defined c-native.
the micro-kernels are meant to use message passing and more abstracted interfaces, as well as separate address spaces to ensure a bad module does not take down the entire kernel. Think of it like the modules run as only semi-privileged applications, handling their hardware and then giving control back to the micro-kernel which does as little as possible to arbitrate control and schedule between the subsystems and user-mode applications. Drivers are no longer fully privileged, and the entire user-space can be considered a subsystem of the kernel.
it's different, and kinda hard to design for, but i can't wait for hurd to release a linux compat layer.
The first rule of USENET is you do not talk about USENET.
Interestingly the chapter was pulled in the 5th edition.. but the chapter was offered online at the time of publishing (it was in my OS class file).
i an
acording to the preface from 5th "coverage of the Mach operating system (old chapter 20), which is a modern os.... is available on line."
Back into relevance? The new article doesn't mention MAC OSX which doesn't mean it completely out of date.
It should be noted that appe hired Avie Tevanian to modify the MACH kernal and boost its performace.
http://everything2.com/index.pl?node=Avie%20Tevan
Yeh, please stop saying this. It's not true and nobody cares about this argument anymore.
I've been swashdotted -- Elmer Fudd
Although Darwin does use Mach at the heart, it also has large chunks of the BSD kernel bolted on to avoid Mach's typical performance hit. Consequently, OS X really isn't microkernel, and you can't do all the cool microkernel tricks (load or unload almost anything dynamically, drivers can't crash the OS, etc).
This approach doesn't make much logical sense to me, but it's what Steve and Avie wanted, and somehow, amazingly, it still just plain works.
How did qnx avoid the problem of message-passing overhead? (Other than being tuned to a specific architecture until recently.)
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
I'm going with GNU/Apple/Mach, just to be safe.
Given this compatibility effort, mach is not a fair comparison, either in hurd or osx, for comparing the merits and performance between that of monolithic and microkernel achitectures because so much extra stuff was added to a design never intended for posix. Something like QNX4 and later, designed both as a microkernel and for posix, or perhaps a pure mach system running applications designed specifically for mach, might be a more fare basis to compare the value of microkernel vs monolithic architectures.
Mach on hurd is easier to grasp and test since many of the lower level mach kernel services are still represented and usable there. Apple seems to be trying to eliminate visibility of as many of the lower level mach services from application developers as possible. Yet, there are still many things that can only be done in the mach kernel on osx or darwin (such as threads that can be cancelled on socket operations or sleeps). If one wanted a bsd/posix compliant environment, I think Apple would have been far better off starting from PPC/xBSD or Linux kernels, rather than trying to rope and rebuild mach to fit into something it was never originally designed for.
"Which design is better?"
What's better? PHP or Python? What's better Pepsi or Coke? The answer is always the same. It depends what your goals/needs/desires are. Neither is "better" in the all encompassing good or bad definition unless you qualify it. Which one's better for performance? Probably the monolithic kernel. Which one's better for security? Probably the micro-kernel. But even then, you have to qualify both of those. Performance of what? Security of what?
I'm sick of all these stupid "which is better?" religious wars that geeks are always so interested in having. What's better? C++ or Java? What's better? IE or Mozilla?
They're all better because the more there are, the more choices you have. There, is that a satisfactory answer?
Linux modules all run in the same address space. Module functionality is invoked with a function call. A microkernel typically uses a message-passing approach and modules are isolated from one another. A small context switch must occur when invoking something in a microkernel module. Hence the overhead of a microkernel is much greater than a monolithic kernel. However many argue that the overheads are worth the organization and safety advantages that the microkernel gives you-- especially nowadays where for typical appliations, the OS accounts for a tiny fraction of overall runtime.
I suggest you go read some about the concepts of latency vs throughput...
use the right tool for the job, be that Linux, mac, windows, whatever
Yes. For instance, if you're wanting to test out the effects of the latest greatest spyware, use Windows and IE to do anything on the Internet.
No, you're mixing terms.
So, the linux kernel supports kernel modules, and its design is to some degree "modular" (as any project that size would have to be), but noone would claim it to be a microkernel.
--Bruce Fields
Yes there is, I am debating you!
In this day and age, there is no reason to use a macrokernel unless your hardware lacks the features needed for a microkernel. QNX has proved this quite nicely.
That's a statement not a criticism by the way ;-)
In general, monolithic kernels run in a single address space and use direct procedure calls / variable accesses to pass data and control flow between subsystems. This is true even if they support loadable modules (like Linux). Any driver or other subsystem in your kernel can (if it wants) access any other part of the kernel.
Although Mach itself is a microkernel, the "xnu" kernel which Darwin / MacOS X uses also hosts other components *in the same address space*. Some of the subsystems (e.g. the BSD subsystem) are large and resemble monolithic systems themselves. The overall system is not a "pure" microkernel, with lots of code moved out of privileged mode. Equally, it's not quite like a traditional monolithic UNIX because of the use of Mach and the other Darwin-specific components (e.g. a (relatively?) stable binary interface for drivers).
It is based on Mach with a BSD compatibility layer
It's not just a "compatibility layer". A Mach system consists of multiple servers providing services to each other and to applications. The BSD server in XNU is an essential part of the system... it's the ringleader, and calls the shots from boot onwards.
Mach must be one of the largest microkernels around. It's also a bit of a cheat - it keeps all the drivers and such inside it. Which means that it's easier to write, perhaps a smidgen quicker, but you loose most of the advantages of such a way of doing things.
I would have thought that you could implement much of Linux in userspace. Certainly file systems and the IP stack could be done easily, leaving just the hardware drivers in there. At that point, you get something that's not a great deal different from the way Mach does it.
Period.
There is no debate. It has been well accepted that micro-kernels are the way to go.
Which is why nowadays it's impossible to find a widely used OS that isn't based on a microkernel!
Andrew Tenenbaum, is that you?
You are completely wrong, dumbass.
Mono vs. micro has nothing to do with modules. They are irrelevant.
It has to do with how system services are provided. In linux (mono) you get a huge amount of services all provided in "kernel space".
In micro, you get small groups of services provided by "user space" daemon processes.
Most BSD's are also mono. Douchebag.
If you hate PDF, use this link: (Note: Not very nice looking)
: www3.interscience.wiley.com:8100/legacy/college/si lberschatz/0471694665/appendices/appb.pdf
http://216.239.59.104/search?q=cache:GRa4T_djMb4J
"Monolithic" and "microkernel" refer to the structure of the kernel program, not to how it's loaded.
Linux drivers (and other "modules") are stored as separate files on disk, or can be compiled in to the kernel. Either way, once they are loaded they form part of the kernel, with all of the rights they need to do whatever they want to your system.
In microkernel architectures, the OS has many layers and a mechanism for keeping them separate, so that the disk driver can't write directly to the screen or affect user processes.
The Linux kernel uses programmer resources liberally to keep separation. There is more and more modularity in Linux as time goes on, but Linus won't ever go fully microkernel because it takes too much away from performance. Better to use "free" programmer time than slow down Linux.
FUD: a Linux module could be or could contain a virus that would have full access to your machine.
Reality: a malware module might mess up your machine, but it would need a really sneaky method of propagation to move to another machine. It basically would have to be part of some distibution to make it onto a significant number of computers.
The malware module problem is also partly why kernel modules should be open source. If you can't see the source, you really don't know what it's doing.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
(n/t)
QNX is a real time operating system - its message passing only has good performance when there's not too many different types of messages to pass. The desktop versions of QNX work if you are only doing a couple things, like browsing and doing email. But if you try to do the things that a Linux distro could easily do, like burning a CD while writing to USB device and compiling a new kernel and running a dozen windows, it'll choke up: it's NOT suitable for a general purpose desktop.
as we switch Steve Job's kernel beans with new Roaster's Light Linux Beans.
Now, let's see if he notices!
Apple's XNU (Darwin), is simply superior in many ways. With the OS X kernel you simply get the best of both worlds, the best things of a monolithic BSD kernel, while a lot of advance features of the Mach microkernel.
Apple's XNU is the way kernels will be in the future. The future is Hybrid kernels. Stop arguing.
Insanity: doing the same thing over and over again and expecting different results.
There is a debate. It has not been completely accepted that micro-kernels are the way to go.
Personally, I wouldn't consider a modular kernel to be monolithic, because it can take many forms. It may have a signle form at any given time, but over any period of time, it may vary that form. If we are going to give the Linux kernel a "technical" description, then "polymorphic" would seem to be more accurate.
However, if we now use "polymorphic" to mean "modular", then there is absolutely no point in having the extra term. We're adding vocabulary without adding any information. So, is it possible to have a kernel with many forms that is NOT modular? Arguably no, because it is only by being able to add/remove kernel code that the kernel becomes polymorphic.
What about the usage of "monolithic" for anything that is a single layer of code, as opposed to a microkernel which is multi-layered with lots of communication between layers? I'm not convinced this is a useful definition. It attempts to identify kernel types by a specific implementation detail, rather than by the design. It would be as useful as trying to classify cats by eye-colour. The relationship isn't necessarily as rigid as all that.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
This is all true, but it's also true that xnu (the os x kernel) is monolithic as well. They've taken mach and the bsd kernel and put them both in the kernel proper. It's not like freebsd is running as some userland process (a la lites) in a typical microkernel fashion.
Does anyone know the technical reasons that Apple (or NeXT) chose to go with Mach rather than BSD kernel?
It's GNU/Apple/BSD/Mach.
Should start saying Apple/Mach now?
I don't think that is needed since more than enough people mock Apple already.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Well I popped over to Amazon to check out your recommended book, and it has one of the worst ratings I've ever seen for a CS book. Really really bad reviews. Either Nutt is at the short end of a conspiracy of mad students, or his book really is too simplistic.
"Linux is a kernel, not an operating system....."
Then what is the name of the OS?
Is it Redhat, Debian, Mandrake; I thought those were distributions?
Is it GNU? or maybe GNU/Linux? HURD?
GNOME? KDE? - Desktops?
It's not UNIX! Or is it? SCO was right?!! ahhh!$@$#
I KNOW! IT'S TUX!
YEAH! That's the ticket! It's TUX!
TUX Rocks!
TUX Rolls!
TUX Rules!
http://www.tux.org/
I don't want a pickle; I just want a Motor-Cycle! A four foot cop arrived with a five foot gun!
How about the popular right-click "Save Link As..." that I've been using since Mozilla Gold 3.01?
How long does it take? I've been using a Mac for over a decade now and I STILL haven't fucked a man.
How does a microkernal affect the updating of the system? in a consumer os that gets updated regularly, does this save on data costs?
Monolithic kernels are dominant in practice (so far). Windows started off microkernel-y but has ended up rather monolithic (at least partly for performance reasons). Xnu (Darwin / MacOS kernel) also has strong monolithic leanings, despite being based on Mach.
The microkernel design still appeals, though. For some things (not all) it is beneficial to move stuff out into less-privileged units. (Small) examples of this in Linux include: FUSE (for implementing non-performance-critical filesystems in Linux userspace), udev instead of devfs, moving initialisation code to the initramfs instead of being in the kernel itself...
Other systems (e.g. Dragonfly BSD) are also seeking to move functionality to userspace where possible without undue complexity and / or performance cost.
Some argue that virtual machine monitors are a useful modern equivalent to microkernels. They perform a similar function (partitioning system software into multiple less privileged entities), although they do it in a more "pragmatic", less architecturally "pure" way.
Virtual machine monitors allow multiple virtual machines to use the same hardware. They have also been used for running Linux drivers in fault-resistant sandboxed virtual machines, with performance within a few percent of a traditional monolithic design (fully privileged drivers).
The L4 microkernel is being used as a virtual machine monitor for this work by one research group, Xen has these capabilities also.
Mach is painfully slow. It's an old microkernel and it uses async IPC (to allow for passing messages over the network). This is slow because you have to do a ton of context switches and copy the message between address spaces.
L4, on the other hand, uses sync IPC. It has a bunch of neat optimizations, but the main reason why it's faster than Mach is that it doesn't have to copy messages. You send an IPC and it goes into the part of your VM space that L4 sets aside for IPC and then L4 does a quick context switch to the target task, it processes the IPC, and then you get your data back. (Simplifyed a ton).
So, microkernels rock. Mach sucks.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
"Mach was the greatest intellectual fraud in the last ten years."
;login, 9/1990
"What about X?"
"I said `intellectual'."
OS X's kernel, "xnu", is /based/ on Mach 3.0 and obviously shares a few concepts with Mach, but is neither a pure Microkernel, nor are all its components from Mach.
Amit Singh has a well-written page about XNU: http://www.kernelthread.com/mac/osx/arch_xnu.html
Mac OS X does not use Mach like a microkernel at all. I wish people'd get this through their thick skulls.
/. would actually edit for content.
It uses Mach and BSD in THE SAME ADDRESS SPACE. As such, it's basically as monolithic as it gets. It just happens to incoporate Mach in the kernel space and uses it for threads and IPC.
Anyone who takes 10 minutes to look at the Darwin documentation would know this.
I wish
mkLinux is not the only microkernel Linux - L4Linux is still maintained and is much more advanced. Nor are these the only Linux kernels to run in userspace - UML Linux, for example, does just fine. It is not clear where XEN fits into the picture.
All in all, though, the situation with Linux is actually a highly complex one, and should not be regarded as being definitely anything.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Here's another way... No extension needed:
* Tools -> Options
* Downloads -> Plug-ins
* Uncheck PDF Extension -> Click Ok
* Click [Ok] again to Exit Options Menu
* Find a link to a PDF and click on it
* A dialog box will pop-up asking what to do with it
* Verify that Open With reads "Acrobat Reader" (or "AcroExch" in the newer versions of Acrobat Reader)
* Check "Do this automatically..." -> Click OK
PDF files will now spawn Acrobat Reader out side of Firefox. This is also helpful on older PC's that slow down to a crawl when opening PDF's within the browser.
The kernel that Apple uses in OS X is called XNU.
It uses code FROM Mach, but it is not Mach and it is not a Microkernel. NT (NT 4.0, NT 5.0 (win2k), NT 5.1 (WinXP) does not use a Microkerenl either.
The only OS that I know of that actually uses a Microkernel is GNU/Hurd.
The OS X kernel, called XNU, is a mixture of *BSD kernel code and Mach kernel code.
Yes, yes, there was a ancient debate between Linus and that other guy about Micro- vs Macro-kernels, and guess what, Linus was right.
Apple does NOT use a microkernel. It does not use Mach. It is BASED on Mach. It would be considured a kludge compared to Linux or FreeBSD, but it works out fine.
Similar to how Mustangs are based on Ford Falcons and Granadas from the late 70's and early 80's. Those cars were as much as a failure as Mach, however the Mustang is flashy and many people desire it. So go figure.
Maybe, you know doing your fucking job instead of reading slashdot would help.
mind if i care?
most of you guys are using free software and not even appreciating it. i find that sick.
guess what, RMS is the reason why linux exists and why we are able to use it productively. he's the single most important reason as to why we still have open sourcecode at all.
if everyone was as ignorant as you are, we'd all be using trashy OS like windows and shit.
i, for my part, am really grateful for the things RMS has achieved and everytime i 'convert' some of my friends and relatives to a gnu/linux system, i'll give them a lesson about copyleft and freedom of information. so should you.
Here is your answer: For the most part, Mac people don't even know what the heck a kernel is. Linux people are nearly required to.
My beliefs do not require that you agree with them.
Although interesting, Mach was developed at a university and shows a huge number of problems as a result. Notably performance is terrible, due largely to the IPC performance. When people actually tried the "collection of servers" operating system in Mach 3, it was clear it was simply not a workable solution. Workplace OS, Star Trek and any number of other OS's died as a result.
What's sad about this is that the failure of Mach tainted ALL ukernels. By the mid-1990s the idea was basically dead. But what an idea! Don't have your machine on a network? Simply don't run the network program. Using a diskless system? Don't run the disk server. Don't want _VM_... no problem. You can use the exact same OS image to build anything from a minimal OS for a handheld to a full-blown multi-machine cluster, without even compiling. No pluggable kernels, no shared libraries, no stackable file systems, nothing but top and ls.
But it just didn't work. IIRC performance of a Unix app on a truly collection-of-servers Mach was 56% slower than BSD. Unusable. Of course you can compile the entire thing into a single app, the "co-located servers" idea, but then all the advantages of Mach go away, every single one.
Now, given this, the question has to be asked: why anyone would still use it? Don't get me wrong, there are real advantages to Mach, notably for Apple who ship a number of multiprocessor machines. But the same support can be added to monokernals. Likewise Apple's version has support for soft realtime, which has also been added to monokernels. So in the end the Mac runs slower than it could, and I am hard pressed to find an upside.
Of course it didn't have to be this way. The problems in Mach led from the development process, not the concepts within. As L4 shows, it is possible to make a cross-platform IPC system that is not a serious drag on performance. And Sun's Spring went further than anyone, really re-writing the entire OS into something I find really interesting, and still providing fast Unix at the same time. I'd love to see someone build Mac OS X on Spring...
If I remember correctly my university years (which is a strech, as most of it seems to be blury and take place in a bar/bars), I did a presentation project on Mach OS. I am pretty sure in was an a Distributed Processing class. That would mean from my fuzzy logic (bullshit) that the Mach OS is a OS designed to be run as a distributed system like Corba (again its all kinda fuzzy). Wasn't it the great sage SCO that basiclly said that Linux is based on their Pripority UNIX code. Since that must be true its purpose and UNIX's purpose must be very close indeed! If you (as the reader) will conside that these MAY be correct and not total bs then that means you are compairing two OS's that were designed for very differnt reasons and purposes. If that is the case it isn't really an apples to apples comparision and thus more complex than a simple than "Linux ROCKS!" or "Mach is a razorblade". Anyway I am really just writing for the sake of seeing mine own words, take with a grain 'o salt.
DarthVain
That is a true statement for the GNU project, but not for all of Linuxdom. Linux (the OS) was not started by the GNU folks. It was started as a separate project and incorporated items from the FSF (and BSD, etc.) into its release. From the beginning the whole OS has always been called "Linux" (search Google Groups for "linux 0.11 author:torvalds" and click on the "Linux information sheet" for an example of this).
Yes, RMS prefers to call the OS GNU/Linux, but that's because he's seeing things from the perspective of the GNU project incorporating the Linux kernel into their work. The rest of Linuxdom see Linux as the name of both the OS and the kernel, and qualify the name using the phrase "the Linux kernel" as an easy way to differentiate between the two.
So, the opening statement in the OS X story is false: Linux is an OS, and is used as such by folks every day. This is the reality of the situation, and it is, at best, wishful thinking on the part of folks who claim it is not to say otherwise.
..wayne..
Couldn't resist http://www.physics.mcgill.ca/~arobic/funny/Gillett e.html
I hope their server holds
Mono vs Macro... what about Exo
...complete system lockup with ndiswrapper beyond a certain version of ndiswrapper and a certain version of the Linux kernel (this is SuSE 9.1 - 9.2 doesn't work at all) Can't upgrade the kernel (or ndiswrapper won't work). Can't upgrade ndiswrapper (crashes kernel). Upgrade both? Complete lockup when running modprobe. Stuck. The monolith wins.
I can't believe that you are modded up for this. Who says that monolithic has anything to do with running in usermode or not? The Linux kernel is highly modular, so not monolithic.
HURD abandoned Mach because of performance issues and is being reimplemented on L4.
If Apple had chosen L4, would it have been necessary from a performance perspective to include BSD at a peer level with the microkernel?
Is it now far too late for Apple to dump Mach?
I'm gay and I'm using a Mac. I was already gay, when I got my first Mac, although I had my coming out 6 years after that.
So if owning a Mac makes you gay, it's a long process.
I would disagree with you there. Apple's design may not be beautiful, but it certainly has the best of both worlds.
The BSD Layer, Memeory Managment, etc are all built inside XNU (OS X Kernel) but at the same time its still functions as a microkernel allowing things such as Kernel Extensions (Kext).
The problem with a fully MicroKernel is that its very slow because of all the context switching that has to go on between userland/and kernel land to do what is essentially kernel functionality. Apple solved this by making XNU not act as a microkernel for things such as the BSD layer.
The result is a Kernel that is less prone to panics. In Linux a bad KLM would certainly panic the kernel because it runs in the same address space as the kernel. In OS X a bad Kext would just die like anyother user space program.
As you said, it may be ugly in your opinion, but it gets the job done, it has the best of both worlds, and its less prone to panics. Now that's what I call a step in the right direction.
Just because it runs on Mach doesn't mean that MacOS X is a microkernel architecture.
Just as an example, on the new MacMini hardware, sound level control is done in kernelspace (since HW doesn't support that anymore)! Whereas the LinuxPPC developers refuse to do things like this in kernelspace.
Actually in Linux many things are pushed out to userspace (think udev), making it much more microkernel-like than MacOSX.
(Not that Apple-Fanboys would understand anything of that)
Mine is still its original dark black charcoal gré. Did you deface your NeXT by respraying it?! Oh, you philistine! And after Steve Jobs went through hell repainting his factory over and over again to get just the right shade!
You're completely wrong. In Linuxland more and more things are being pushed out to userspace (where it makes sense: e.g udev). Under MacOSX things like soundmixing is done in kernel space!
"I can't believe people are modding you up for this."
I can. Maybe you're too young to remember when the term monolithic was commonly used to describe a kernel which, instead of using loadable modules, was linked as a single binary image. This was, and is, a valid use of the word. Here's an example.
The first time I heard someone say that Solaris is monolithic, I thought that they were saying that, like SysVR3, it didn't support loadable modules. I didn't realize that, with the development of microkernels, the term "monolithic kernel" had started to be used in a different context.
First of all, having modules or not has no effect on being monolithic. The entire kernel is a single process that simply executes code, wether its compiled into the kernel, or loaded into the kernel as a module makes no difference here. Microkernels actually have seperate processes for different parts of the kernel, and they cannot execute code from each other, they must communicate back and forth using some sort of message passing system.
And second, no BSD based kernel forces you to use modules. Have you actually tried any BSD? Modules are entirely optional, just like linux. In fact, openbsd's kernel only has support for modules, but nothing is actually compiled as a module, and using modules is unsupported.
Google for Avadis Tevanian.
> QNX uses shared memory to pass messages
So does Mach, and it's slow. I've never seen real-world measures to suggest that QnX is fast. All we know is that the performance of the OS itself is good, and that's a VERY DIFFERENT measure.
The slow performance is due to a number of problems:
1) not all MMU's are really suited to this task. Many are slower to set up than just copying the memory around. Sun found this to be at around 5k, below that, it was faster to just copy memory physically.
2) MMUs/VM are based on pages, 2 or 4k typically. Thus passing in a single 32-bit int parameter causes big page hits. You can tune this out, but it's still annoying.
3) Each copy takes TWO context switches - one to switch into the kernel to copy the memory across ports, another back out to the called program. This means that even the simplest "system calls" are twice as slow as under a monokernel, AT BEST.
4) Additionally the data has to be examined to see if it contains ports being passed around, and if so, they have to be translated because the port codes are private to a program (and thus different in the other one).
5) Using mapped memory ignores all the hardware specific solutions to these problems, many of which are built into modern processors.
It's exactly the sort of one-size-fits-all solution that you'd expect from a research project. One that doesn't work in the real world. One that should have been replaced, and was in L4, Spring, etc.
For instance, Spring included three different IPC systems, each tuned to certain types of data, each used in different ways on different CPUs. The "fast-path" used a half-switch into the kernel by mapping off registers, allowing IPC to degenerate into register passing largely identical to a procedure call. As long as the message fit within the limitations -- 8 registers, no port identifiers, etc. -- it was faster than a traditional Unix trap. These limitations seem serious, but were in fact used for 80% of calls and 60% of returns (you often say "getDiskSector(integer value)" which could fit into the fast-path, and get back 2k of data which wouldn't).
Maury
Linux is in spirit a monolithic design, and MacOS is in spirit a mach-based microkernel design.
In reality, though, both MacOS X and Linux have departed from the architectures in mostly pragmatic ways. OS X is not a "pure" microkernel in the mach sense.
you're crazy, a RTOS is designed to handle that kind of load. On a submarine or on your PC. That's what real-time means. Next time XMMS starts stuttering when doing a compile, remember that you're using a non-RTOS
Linux modules do not run in user-mode.
You mean like the whole BSD-Subsystem of MacOS doesn't run in user-mode?
The parent is not informative. Although his statements are correct in the context of this story, there are in fact more than one meaning to the term "monolithic kernel".
The problem with a fully MicroKernel is that its very slow because of all the context switching that has to go on between userland/and kernel land to do what is essentially kernel functionality. Apple solved this by making XNU not act as a microkernel for things such as the BSD layer.
The result is a Kernel that is less prone to panics. In Linux a bad KLM would certainly panic the kernel because it runs in the same address space as the kernel. In OS X a bad Kext would just die like anyother user space program.
In xnu, KExt's are not userland processes. They are kernel extensions, just like on most other *nixes. I don't know where people get these patently false notions.
From the documentation...
Kernel Extension Overview
As discussed in the chapter "Kernel Architecture Overview", Mac OS X provides a kernel extension mechanism as a means of allowing dynamic loading of code into the kernel, without the need to recompile or relink. Because these kernel extensions (KEXTs) provide both modularity and dynamic loadability, they are a natural choice for any relatively self-contained service that requires access to internal kernel interfaces.
Because KEXTs run in supervisor mode in the kernel's address space, they are also harder to write and debug than user-level modules, and must conform to strict guidelines. Further, kernel resources are wired (permanently resident in memory) and are thus more costly to use than resources in a user-space task of equivalent functionality.
In addition, although memory protection keeps applications from crashing the system, no such safeguards are in place inside the kernel. A badly behaved kernel extension in Mac OS X can cause as much trouble as a badly behaved application or extension could in Mac OS 9.
Bugs in KEXTs can have far more severe consequences than bugs in user-level code. For example, a memory access error in a user application can, at worst, cause that application to crash. In contrast, a memory access error in a KEXT causes a kernel panic, crashing the operating system.
Python, and mozilla are both significantly better than what you compared them too. And C++ vs Java is like monolithic kernel vs cheddar cheese, they aren't designed as or used for the same things at all, so of course neither is "better".
The only comparison of yours that really works is coke vs pepsi. And obviously the answer is coke.
Hey, shit isn't a trashy OS. It's intuitive, requires minimal hardware, does automatic garbage collection, and even supports logging.
While many devices are not supported, and the performance is not good, HURD/Mach is feature complete (and most of Debian runs on it, IIRC).
Because the performance was bad, the new HURD effort focuses on reimplementing on L4. Perhaps with a faster microkernel, Apple could have avoided the kludge of an in-kernel BSD peer.
If I am reading correctly, Mach is responsible for IPC in the Apple kernel. It would be interesting to see benchmarks of SYSV system calls to semaphores, queues, and shared memory (and perhaps even basic signal handling) under Linux and the Apple kernel on the same hardware if those are entirely handled by Mach.
> Windows started off microkernel-y but has ended
> up rather monolithic (at least partly for performance reasons).
I've heard this claim before, but I'm not sure what to make of it. I always suspected this claim comes from MS's marketting efforts, trying to make it cooler than it is. Remember, back then ukernels were still "cool".
But the only actual example I can think of is the display driver, which used to run outside the kernel. AFAIK most everything else is done internally. And even the display driver used some sort of custom data-passing system, as opposed to a universal IPC, did it not? All of this is fuzzy... forgetting past...
Maury
Pffffftttttt....
LISP roxxorz!!
Context switches are not rediculously slow on all architectures, so "a ton of context switches" isn't that big a deal unless you are using a poorly designed architecture that hasn't been improved, ever.
I admit my error :-). Thanks for correcting me.
Is there a way then to extend the kernel through userland modules in XNU ? If its a microkernel then there should be a way, right ?
I am not sure this last has a lot to do with the fact they are using a microkernel. You can run the Linux kernel under Linux in usermode. You can run the linux kernel under win32 in usermode.
However...
The Linux kernel is monolithic. Linux modules do not run in user-mode. They are loaded into the kernel proper.
Are you suggesting that if you could load (and run) modules in usermode in Linux it would then be a microkernel?
There is an undeniable advantage to having drivers code run in ring0: performance and cleanliness. There is an undeniable advantage to allowing drivers to run in userspace: per user customization of the envirenement, but you will certainly take a performance hit( you cant make that MMU run any faster than its fastest, so I dont think this is arguable ).
There are probably many more, I just wanted to stick with the most fundamental aspects as I see them.
To some its a clear cut case as to which one "wins", but to others like me, we see tradeoffs.
But mostly, in the end, when all issues are considered and calculated, it comes down to one thing: flame war.
I think you underestimate just how much I just dont care.
While RMS was busy trying to spread his own breed of GNU/communism, BSD happened. And linux would likely still exist without the FSF anyways, it just wouldn't be GPL, Linus could have written a simple license of his own, big deal. The only significant contribution the FSF has made is their buggy and slow compiler/toolchain. Quit buying the RMS lies that he is the sole cause of the concept of open source software, and is thus responsable for all open source software in existance.
xnu isnt a microkernel in any real way. Of course, apple has tried pretty hard to limit the number of things you need to be in the kernel for, and when you do need to be in the kernel, they have provided frameworks (iokit, for ex) to make the development of the driver code easier.
I believe the short answer to your question is no.
Your point about simple system calls is pretty wrong. Sure, the simplest system call that has no real body will execute twice as fast without extra context switching, but if the system call is non-trivial, then the context switch overhead becomes a small percentage of the time. So at worst, it's twice as slow, and at best, it's just as slow. ;) Thus is the folly of microbenchmarking--it doesn't measure system performance, just how fast you can do one thing. The real problem with microkernels is that you can always do in a macrokernel what you can do in a microkernel, it's just more engineering effort in the kernel and possibly requires a reboot.
Machintosh?
Machinetosh?
Machinetoss?
Next time QNX burns you a coaster because a network interrupt occurred and was prioritized over keeping the cdrom buffer full, remember you're using an RTOS, which is not at all designed to handle anything that resembles a desktop situation.
There is one very easy way to kill a microkernel's performance - force it to use a synchronous system call API (e.g. POSIX). With a synchronous system call API, a context switch is required for every system call. With an asynchronous API, the process simply writes messages into a buffer (or set of buffers for different kernel services) until it either needs to wait for a response or its quantum expires. At this point, you switch to the next context (perhaps a kernel server) and process the incoming messages. This reduces the total number of context switches (and, more importantly the number of mode switches). If you want to see good performance from QNX, then use the native system call API, not the POSIX wrapper.
I am TheRaven on Soylent News
Your sig is misleading. It begs the question, "is there a pc that is equivelent to a mac?".
Actually that's an EXCELLENT point... by your rationale we should actually stop calling it OS-X and just call it Mach, since the kernel apparenlty gets to name the whole OS. Oh wait, you say that the rest of the OS took a lot of hard work to develop? Maybe calling Linux just plain GNU would make more sense.
Jeremy
Ahem, the point the poster was making was about modern desktop computers going multicore, in which case you cannot discount the possibility that the message will be going from an OS process active on one core to an OS process active on another core. This can potentially involve zero context switches. So "AT BEST" would not be twice as slow...
Actually, monolithic kernels will always be faster... in fact why not make all software monolithic? What I am talking about is running all programs in the kernel address space with simple function calls to kernel services. That would make the computer much faster, and it can be done.
If the entire operating system were written in a safe language such as Java or C# ("managed" code only) then the performance impact from syscalls, virtual memory (TLB flush/lookup), complicated task switching, and extra copies of data from/to the kernel would be almost entirely eliminated. A safe language is one that does not allow arbitrary pointers.
FYI, in a linux 2.6 kernel on a 512 meg machine 4 megs is taken just to have page tables -- not even including the overhead when processes actually add pages to their memory spaces, just to have support for VM in the first place. Syscalls take ~1000x longer than normaly functions, so they are always going to be a bottleneck. And when you call a syscall that takes a data parameter (string for instance) the data is in the best case copied (in the worst case the kernel sets the address of the reading instructions in a table, then a page fault happens and the fault handler checks the table to see if the access was okay). IO using read/write is always copied at least twice, and even mmap suffers from a lot of overhead from the kernel managing the pages.
Basically kernels written in C or other archaic systems programming language are needlessly slowing down the computer a LOT. With a safe language for instance, instead of using the virtual memory to force programs to not mess with each other, they simply can't do that so the VM can be used for other things. One nice performance enhancement is to allocate all memory (objects) in a 'new' zone and use VM to track what pages have been written to; when the 'new' zone fills up only pages that have been written to are checked for references during garbage collection. So basically you could do 1 billion memory allocations of arbitrary sizes and it would take only 1 billion instructions (each allocation increments an integer and that's all). Also, "system" calls are then just normal method calls and can even be inlined, so instead of getpid() taking the time of 1000 instructions it could easily take only 1 (direct inlined access to the variable).
So lots of people will mod this down since they assume that the low-level details like cache lines are more important than oh, say, free memory management. But I got some news: a few minor tweaks and you can do all that same low-level crap in Java or managed C# and get all the benefits of a safe kernel.
You are using "begs the question" incorrectly, wiseguy. :)
XNU is essentially a monolithic kernel, much like Linux. The real differences, in my opinion, lie in the IOKit object oriented driver API, whereas Linux has no real driver API and drivers have complete access to all kernel functions as drivers are simply kernel modules.
No, it should be called by whatever Shiny Pretty is doing the GUI desktop. That's all that people care about, and no one sees the GNU utilities.
One line blog. I hear that they're called Twitters now.
>My point is that writing a new operating system that is closely tied to any >particular piece of hardware, especially a weird one like the Intel line, >is basically wrong. -- Andy Tanenbaum 30 Jan 92 13:44:34 GMT
Whats wrong with Right click, Save link as... ?
My point was limited to the time for the switching itself. Perhaps I should have been more clear on this.
The "at best" is assuming that the forgoing issues don't cause things like cache faults. Passing parameters in registers won't. Thus the performance really can be MUCH worse than twice even in the case of minimal calls.
But even in that case the real-world performance of Mach is, in fact, much worse that twice as slow. I believe it was Chan that did all the big measurement runs, and - going on memory here - BSD on a 50MHz 486DX took 21 usec per syscall, and Mach 3 on the same machine took 114. I may have the number for BSD wrong, that might be the L4 number, BSD might be 9 usec.
The other case is, in fact, even worse. This is the case where the system is constructed of a number of cleanly separated servers running as Mach tasks. In this case a system call may spawn off a series of calls, consider a page fault in the VM for instance. In this case you might end up with a chain of 5 IPC's causing traps. And each one of them is 5-15 times as slow. This is real-world noticable, even for I/O.
One of the papers I have on L4 shows theoretical peak and sustained network throughput for IP on Mach, L4 and BSD. Mach had about 1/10th the performance IIRC. So that "best case" is pretty rare.
Maury
You can't download the binary of a driver, tell the kernel to load it, and expect it to work unless the person who compiled just so happened to have the exact same version info, and by some miracle the same compile options.
Yes, distros like RedHat and SuSE do have binary drivers for download, BUT ONLY if you stay with the stock kernel.
Just because you can "load modules" doesn't mean you are suddenly a microkernel. God it's like monolithic has become a swear word, it's a perfectly valid design.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Funny and insightful. Great point!
What changed under Obama? Nothing Good
- its Gnu/Linux
its GNU/Linux
Linux is for the kernel
GNU/Linux is for the OS
its the right and legal way to mention it. You whont get killed if you call it Linux , you will just show that your clueless.
To clear up any confusion: No *BSD uses a microkernel. (The only part of OS-X that is *BSD is the userland, which is derived from FreeBSD). The *BSD's are basically in the same classification as Linux/Solaris/HP-UX or any other UNIX or *NIX clone. Which means: all the *BSD's are monolithic in nature, with some modular abilities added on in recent years. Like Linux, the *BSD's can load a kernel-module upon request (either during boot, or upon superuser-request). These modules can also be compiled into the kernel itself (which is sometimes a good idea, as it saves a small amount of memory and improves performance).
Anyhoo, back to the original topic: The MACH microkernel. Apple's implementation is excellent these days, but it definitely went through its struggles (which is one reason why we continue to see major speed improvements with new versions of OSX, even on older hardware). Creating a monolithic kernel is difficult enough, but to create a micro like MACH, and do it properly... that takes serious skills. Mad props, Apple engineers.
/dev/random
"For the most part, Mac people don't even know what the heck a kernel is."
Mac people know what a kernel is , but they know its illegal for them to change it , modify it or resale it, so they work on other things if they do the previous they will get sued into oblivion.
GNU/Linux OS user are not required to play with the kernel at all , but unlike for MAC they are given the right to do anything they wish with it.
To couch them in terms of Monolithic versus Micro would be like trying to classify an economy as Capitalist or Communist.
Neither economy has ever existed in it's pure form. Both descriptions also have political overtones that have precious little to do with their actualy description.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Actually, wouldn't that be Mac/Mach?
Does it make you happy you're so strange?
I don't think you can say message passing is a feature of microkernels exclusively. DragonFly BSD uses a message passing interface internally to it's (IIRC) macrokernel. I did some work to a new device driver model that is now part of UnixWare that is definitely more message passing than API calls.
"By all definitions Linux is monolithic."
By *all* definitions? No, I already showed why that isn't true.
"You can't download the binary of a driver, tell the kernel to load it, and expect it to work unless the person who compiled just so happened to have the exact same version info, and by some miracle the same compile options."
You can't load code from a Univac either. That's beside the point.
"Just because you can "load modules" doesn't mean you are suddenly a microkernel."
Who said otherwise? My point was that there is more than one meaning to the word "monolithic" as it relates to an OS kernel.
"God it's like monolithic has become a swear word, it's a perfectly valid design."
You're reading way too much into what I wrote. Linux *is* monolithic in the sense that all of its components run in the same address space, and I'm not claiming that a microkernel would be better.
I don't understand why everybody says mac os x is a microkernel - it is not a microkernel. A microkernel most of the thigns in userspace. Mac os x moved _lots_ of things to kernelspace to save performance costs
Hence, Mac os x is not a microkernel. They started from one - they are NOT one. It's not different than linux in that HFS or a driver can hang your box if there's a bug somewhere. It's no different than linux in that they're well-layered. They're not really THAT different, really - and NT is not really different either. I mean, those things have been studied, there's no "hidden magic".
Maybe some people consider the mac os approach cleaner, personally I don't. If you're going to do a real microkernel, implemente everything in userspace and use message passing, do it. However if you're not going to do a real microkernel, why do you start from one and keep the message passing? May be some people find it "clean"...but message passing was done to write real microkernels, there's not need of it in a kernel that has lots of things in kernelspace like mac os x does. Do it the linux way - cheaper, simpler, less complexity....(this is why linus hates mac os x, they use microkernel funcionality to implement something that ends up being like traditional microkernels - lots of things in kernel userspace - so why not do it more KISS and kill message passing completely like linux does? You can do a good design anyway, design is not tyied to use messages or not)
(Of course, both ways work)
That's certainly one cynical viewpoint, but is not what really happened. Linus started his own OS project and he named it as he pleased (or really those around him named it and he accepted the name). There's nothing wrong with naming your own project and then cherry picking the items you want to be in your project from the available choices. Keep in mind that the GNU folks were working on HURD at the time, and were not all that keen on the Linux kernel. So, this was not a case of someone coming along and completing the GNU project (at least, not at that time) -- this was a different OS project that shared a lot of the same code. In some ways it could be considered to be a fork, but even that is not right conceptually because the project didn't start out to be a GNU system. If the BSD utilities hadn't been under a cloud of a potential lawsuit, it may well have been that more BSD code would have made its way into the early versions of Linux (IIRC, the GNU tools were slightly buggier but more feature rich than the BSD tools at the time).
Stallman tells us the call a GNU system running on Linux GNU/Linux.
Stallman has every right to advocate that based on the perspective of someone close to the GNU project, and I have every right to ignore him based on my historical experiences with Linux from as far back as version 0.11 (I switched over from Minix to Linux, and helped Remy Card with some of the early work on ext2, so I've been using Linux for a long time).
..wayne..
"Just because you can "load modules" doesn't mean you are suddenly a microkernel. God it's like monolithic has become a swear word, it's a perfectly valid design."
Indeed. Just like a microkernel doesn't makes it suddenly "a better design". It's perfectly possible to write a microkernel with a ugly design (And mach is a good example of a _bad_ design, there're reasons why Hurd developers are going for L4). And that's because "design" has nothing to see with message passing or monolithic - it's perfectly possible to write a monolithic kernel with a wonderful design and very mainteinable. Message passing just encourages it. And give that mac os x is not a microkernel - they moved lots of things to kernel space because of performance, hence they're not a microkernel - linux and mac os x are not really that different.
I hate flamewars, but as been said by many people many times, RMS does not get to define opensource. OpenSource existed long before RMS, and will exist after his demise. If you want to talk about fighting for open code, remember that the Regents of UCB fought for opensource code in a court case, and can say that they won.
RMS is very important, but he's a zealot, and a lot of people don't agree with his views (I for one don't on a lot of issues). Don't get caught up in the whole Saint iGNUcious thing.
At least according to Andy Tanenbaum who said on 30 Jan 92
Where is Hurd today? from GNU
And as far as running free GNU on their SPARCStation?
We also know about the superiority of the NT Microkernel.
I use a Mac, you insensitive clod!!
"The objective of securing the safety of Americans from crime and terror has been achieved." -- John Ashcroft
Only one mouse button ... :)
You always point your finger at the bad guy, but what if the bad guy points his finger at you?
Or, to keep it simple, just Mac(h). Or Mach? for you regexp people...
All's true that is mistrusted
The MACH kernel is brand new fighter pilot simulator, she thought so then deleted it at MACH 10.
Peace
Gawd. You obviously know how to jerk some chains Epiphani... I mean it is GUARANTEED that you will get into a useless and heated argument if you even mention Monolithic in a sentence. You might as well compare Pico and Edlin or the merits of a Command Line.
Everyone knows that the entire computer is a module in userspace.
>>"ad space available -- low rates!!!"
The original poster is almost right. Windows as in Windows 3.0/3.1/95/98 and so on (including earlier unsuccessful releases) were not designed using a micro-kernel approach. Many would argue that they were not designed at all. Windows NT 3.5 however was designed with micro-kernel architecture. Well, as close to a micro-kernel as Redmond has been able to achieve. However NT 3.5 suffered from significant performance issues. Some of these issues were seen to be a result of the layered microkernel approach. To address this, NT 4.0 moved many of the upper layers down into layers 0 and 1 and provided the ability for driver writers to install services into the lower layers. This was great for performance reasons since now drivers could make direct calls rather than message passing to the kernel services. However removing the separation started the rot of stuffing more and more things into the lower layers effectively transforming a micro-kernel into a monolithic kernel. The fact that these extra things stuffed into the kernel space have varying levels of QA and compatibility testing caused a trend to reduced stability in the resulting OS.
There seems to be a bunch of carping on this thread about large files and the "Super Slashdot Effect". Why not set up a torrent server for these poor links and let the poster and the readers actually get what they want?
Cutler wrote a book on it, which is still worth reading, though out of print. Microsoft has a current "XP Internals" book available from Microsoft press.
Also, Microsoft has an XP-based embeddable operating system, which eliminates many of XPs "desktop" enhancements. And of course, the excellent handheld operating systems that are the heart of Windows Mobile.
Best Buy can have you arrested
guess what, RMS is the reason why linux exists and why we are able to use it productively. he's the single most important reason as to why we still have open sourcecode at all.
Not true. The single most important reason why we have open source code was "consent decree" from 1956, when Justice Department agreed to drop charges based on Sherman Antitrust Law against AT&T in exchange for compulsory licensing of all technologies developed by AT&T to American public for "nominal fee". When Bell Labs - part of the AT&T empire - developed Unix, they were obliged to supply source code to basically anyone who asked. That's how the open source Unix culture was born. RMS - with all due respect - has joined it quite later, when it was already florishing.
....XNU is. It is partly based on Mach, however it is also NOT a microkernel, as many of the BSD subsystems that normally live in userspace are incorporated into the XNU kernel. I'm (not) surprised that no one has pointed this out.
Amit Singh of Kernelthread.com has an excellent handful of articles on OS X kernel and filesystem details.
[QNX]...performance is far better than Linux...
As someone who actually evaluated and used both linux and QNX for embedded projects, I can say - not by a long shot. QNX is a very nicereal time operating system, with predictable interrupt timing and all that. But performance-wise it suckus-dickus. Too many context switches.
Real-time operating systems have different design criteria than "normal" desktop-server OS, like linux. In general purpose OS you care about performance, which is average-case behaviour. In real-time OS you care about worst-case behaviour, which is a very different thing. You need things to be always predictable, even if they are not always efficient.
still intersting and in some kind very funny the tanenbaum vs. torvalds debates about microkernel vs. monolithic architecture
Well, there's theory, and then there's practice. A RTOS is generally designed to run one application in real time, not an arbitrary set of apps launched at random.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
I'm really happy I could help.
A) it was easier
B) it eliminates any problems with dependencies like apps that are currently running and using the sub-system that was upgraded. (see A)
I.e. Software Update often requires a restart because doing so enables Apple to release the update several days earlier than would be possible if they had to do all the necessary coding & testing to ensure that the update would work without a restart.
They are pulling a lot of stuff back into usermode for Longhorn. USB device drivers will be usermode, GDI will be software rendered in usermode, the new unified audio architechture is usermode. Basically only drivers that need to access hardware registers directly will remain in kernel mode.
They are also changing the driver model to make writing drivers easier, so individual drivers do not have to reimplement plug and play and power management support etc. I guess they think that hardware performance has improved enough that it is worth sacrificing speed for stability.
"Taligent is still pure vapor. Maybe they'll be the last who jumps up on Openstep... "
James M. Kilts has new plans.
Mach has an interesting feature where a user app can add its on private system call. This could come in very handy for a emulator. My question is how is this done under OS X in a way that will continue to work with new releases?
Its message passing is very lightweight, and the resulting performance is far better than Linux.
Faster than passing arguments in the stack? Oh wait, we have an option to pass arguments in registers in linux 2.6. Is QNX message passing faster than passing arguments in registers? Somehow, I doubt it...
Is there a way to run Linux, say as a user-mode program, under OSX, letting Linux app binaries call the Linux kernel, alongside "native" OSX binaries calling the Mach kernel? Assumed exclusive kernel access to HW seems the biggest problem, but can it be solved through some kind of HAL that creates a virtual HW interface for each kernel, running under Mach for conflict resolution? Does OS virtualization layer software do all this at an acceptable performance cost?
--
make install -not war
Yes, but once a module is loaded, it failing can take down the whole system because the module is loaded into kernel space. A microkernel by definition is nothing more than a message passing interface that lets various user space processes handle everything else.
God save our Queen, and Heaven bless The Maple Leaf Forever!
Command+click.
:))
(In all honesty, that's one troll that never made much sense... though, I guess that's the point of trolling
If the OS X kernel is soooo slow being based on Mach, then why does it offer the lowest latencies in audio recording? Why are almost all of the major audio production houses (and home studio operators) use Macs? Pro Tools is tuned to run best on a Mac, Logic is Mac-only.
[No text]
One of those things you have to get *really* correct. When its good, its *VERY* good, and when its bad, its bloody horrible - in laymens terms.
Sounds like the debate between 1:1 threading vs M:N threading - when M:N threading is done properly (like in Tru64), its a bloody great idea, but when it is shithouse, as the case of Solaris (prior to Solaris 9, now replaced with 1:1 in later Solaris 9 release, and default in 10), its horrible to the point that no bastard would want to touch it for all the tea in China.
It's actually Control-click. It's not a troll if you're a Mac user. ;)
"The objective of securing the safety of Americans from crime and terror has been achieved." -- John Ashcroft
I'm not so sure. For an equivelent pc to be cheaper than a mac it is necessary for such a pc to exist. Therefore the existence is presupposed by the statment, and it begs the question, since the statement is that pc's are better than macs due to price.
So again,
statement ~:PC's are better than macs because of price.
presumed 'fact':there exists a PC that is equivelent to a mac, varying only on price.
but the very fact being debated is which is better. So he assumes they are equal, and then says pc's are cheaper. This is begging the question, since he asks that we concede the equivelence of some PC's to macs, which is the very point of contention.
Touche.
Hopefully you've got that BURN-PROOF technology.