Talk:Mach (kernel)

Licensing

Under what license(s) might the Mach kernel be acquired? There's no indication of this in the article, and a cursory Google search has yielded no information for me. If someone has this information, it should be added. -- Apotheon 20:32, 19 May 2007 (UTC)

I had the same question. It appears to have it's own license, if you follow the links through to the official project page, but I don't feel comfortable add information about the license to the article, I don't think I have a great grasp on the material. Here's the link though, in case someone else can make sense of it and make the change. --Balleyne (talk) 22:35, 20 March 2008 (UTC)

There also appear to be some freely distributable (public domain) parts: [1]. I added this info to the article, but we still need to figure out the license for Mach 4 from the University of Utah. I suspect it might be public domain. -- Beland (talk) 15:11, 6 March 2009 (UTC)

Pronunciation

How is the word "Mach" pronounced? Like "match", or like "mac", or like "mash", or like German "Bach"?

This info is missing in this article. It should be included. In fact, there has been quite a bit of discussion about this question.

I've always presumed it was named after Austrian physicist Ernst Mach, and was pronounced the same as his name (like Bach). Qwertyus 16:13, 21 March 2006 (UTC)

I always figured it was pronounced as in "Mach number", which is pronounced like Ernst Mach's name. – Mipadi 16:21, 21 March 2006 (UTC)

But then some webpages say it is pronounced like "mack"? Any other opinions out there? Let us know.

I said I had it was named after Mach. I'm not sure and have removed this unverified info from the page. It may also have been named after him indirectly, via the Mach number. That page says: "Mach number (pronounced "mack" in British English and "mock" in American English)". Qwertyus 00:06, 23 March 2006 (UTC)

Thank you, Qwertyus. OK! Now, is there anybody around who knows how (and why so) it is pronounced? Somebody should know! After all, one has to talk about it not only write.... :-) Thank you in advance.

I add here a link to the discussion on the pronunciation on the Mach number page. Maybe we get some info in that way.

Okay. I know for sure that in US English it is pronounced "mock".--File:Nuvola apps kcmmemory.pngMac Lover ^Talk 17:24, 10 August 2006 (UTC)

If it really is named after Austrian physicist Ernst Mach and/or Mach number (as for speed) then it should be pronounced with Hard ch same as J.S.Bach or Scottish 'Loch' (IPA: [max]) —IEEE (talk) 01:23, 30 September 2008 (UTC)

I worked on the Mach project at CMU in the 80s. It's pronounced "mock." (Well, maybe more "mawck") When Rick was thinking about naming the system, there were a number of tentative names floating around, one of which was "muck." He was discussing real names with a colleague, Dario Guise, who has an Italian accent. Dario asked him what the working name was, and Rick said "muck." Dario said, "Ah, mach!" (mispronouncing it with his Italian accent), Rick loved it and it stuck. Other possible names were "Moose" (favored by Mike Young) and "Melange" (from Bob Baron, and which I was very fond of because Mach was in some sense a union of the old Spice project with Unix, "melange" was the spice from the Dune books, and "melange" means mixture). Since I'm an original source for this, I don't know if I should edit the page with it, so I'll just leave it in discussion for now.--Bill Bolosky —Preceding unsigned comment added by 131.107.0.77 (talk) 03:27, 10 February 2010 (UTC)

Here is a video of Steve Jobs pronouncing it as mock. Obviously there are other sources, too, that you may look up for yourself, for example 24C3: Inside the Mac OS X Kernel. Just thought it's worth mentioning. Dalba 10:14, 8 March 2016 (UTC)

Avie Tevanian, etc.

Perhaps we should mention Avie Tevanian here, too. ("Tevanian was an important figure in the development of the Mach kernel while at Carnegie-Mellon.") I think it's very interesting that two important Mach developers are now at top positions in Apple (Mac OS) and Microsoft (research).

Quite a few members of the Mach team came to Microsoft when Rick Rashid started Microsoft Research. Rich Draves, Joe Barrera, Alessandro Forin and me (Bill Bolosky), as well as Bob Fitzgerald, who'd worked on Mach's predecessor, Accent.

Is it still correct to state that the GNU Hurd is the biggest Mach project to date? Darwin's pretty popular as far as kernels in commercial OSes go. BonzoESC 00:04, 4 Dec 2004 (UTC)

I don't have an actual source, but didn't Apple say at one point that there were the biggest seller of desktop Unix now? AlistairMcMillan 02:12, 4 Dec 2004 (UTC)

The article actually needs a quite a bit of work. At one time it was thought that Mach would slowly take over the entire operating system universe, but this has not happened. Except that the most popular operating system in use right now (Windows NT/2K/XP) uses a kernel based partially on the work done on the Mach project. AlistairMcMillan 02:12, 4 Dec 2004 (UTC)

I do not believe this is true. NT uses a classic monokernel, does not use IPC for much of anything, does not make extensive use of user-space servers, and is millions of lines long. NT was a development of VMS, not Mach. Maury 12:50, 23 Mar 2005 (UTC)

Is it true, that MACH stands for Microkernel Architectures Considered Harmful?

That's more of a [backronym] than anything else. That's like if FORD stood for Found On Road Dead, Fix Or Repair Daily, or anything that's not some dead dude's name. BonzoESC 18:59, 23 Dec 2004 (UTC)

No, it definately is not true. Since Mach is a microkernel, it wouldn't make sense for that to be the acronym. "Mach" isn't an acronym at all, and shouldn't be spelled in all caps. See my comments on the name in the pronounciation section above. --Bill Bolosky

BeOS

There is at least one more microkernel system that's left out of the article and that had decent performance: BeOS. Unfortunately I don't know much details, but the system had a real microkernel and servers like input server, application server, media server, net server, etc. In addition, it was and is very fast and responsive, in some cases faster than a Linux system. (Purely from user perspective.) It should be worthwhile to try and dig information about it, as it seemed to be a succesful microkernel based OS. --W-ber

the categorization of the BeOS kernel was discussed extensively on the Kernel article. The documentation describes it as a microkernel, while the developers described it as "modular monolithic." Eventually we reached a compromise and decided to place it under hybrid kernels unless a clear source shows otherwise. MFNickster

size of traditional kernels in lines of code

As the capability of computers grew, Unix became increasingly cluttered with code; while early kernels might have had 100,000 lines of code, modern kernels have much more. For example, Linux, a Unix successor, has over 33 million lines.

The comparison with Linux is off-key because back when the first Mach was released, Linux did not exist. We need a number of lines of code in a SVr4 kernel or similar. --Joy [shallot] 22:17, 18 Jun 2005 (UTC)

POV, confusing sentences, and historical information

I think the sentence The ultimate "classic" operating system is Unix, so any discussion of more modern systems must start with that one is useless and seriously POV. How does one define "classic" and "modern"? I don't want to enter the debate of what has Unix invented, but this claim is dubious; secondly, even if we admit that Unix is "the ultimate classic OS" (whatever that means, and I really have no clue what it means), it's not clear one can infer "any discussion of more modern systems must start with that one" from that. I suggest either rephrasing that as "Unix being one of the major modern operating systems, we shall start our discussion with it", or something along these lines. Or, we could simply remove this sentence, which IMO does not provide any information about the subject at hand.

Also, I don't understand what is meant by Another ongoing issue was properly handling computing resources: users spend most of their time staring at the screen instead of actually using their computers' resources, and the time share system should give the CPU time to an active user during these periods. What are these periods? To me, this sentence actually describes a non-timesharing system, and such description is unappropriate in this paragraph which is supposed to describe the problems of this era's timesharing systems.

And finally, I don't think that Unix invented pipes; ITS does have pipes (used by accessing the CLA, CLI, CLO and CLU devices), in all versions I have used, and they are described in the revised ITS reference manual, section 3.4.3 (July 1969). Unfortunately, I have been unable to determine from what version on pipes were implemented in ITS, so I cannot be sure which system had them first; anyway I seriously doubt ITS' pipes were implemented after seeing Unix's pipes; more likely the two systems developed pipes independently; oh, and note ITS's pipes worked across the network (since ITS's filesystem is nertwork transparent, it is not really surprising). Well, the article does not claim Unix invented pipes, but it does imply that the fact one can manipulate files through many little programs was invented by Unix; perhaps Unix was the first system to be described as having this philosophy, but one could and would definitely manipulate files using many small utilities under ITS, so I think this needs a rephrase. Sam 17:39, 29 December 2005 (UTC)

IPC performance

Roughly paragraph 10 under "Mach concepts" starts with a sentence that sounded weird and redundant the first few times I read it, "Performance of the IPC system was an initial performance problem..." It seems like the word performance shouldn't be in there twice. —Preceding unsigned comment added by 15.252.0.75 (talk • contribs) 18 april 2006 21:42

Fixed. Next time, please be bold! Qwertyus 23:55, 18 April 2006 (UTC)

Missing citations

Does anyone have sources for the citations that are missing from this page? There are a lot of statements that read as if they are facts but without citations who knows.

Long-winded, repetitive, and in some ways confusing

IMNSHO the entire article could do with an overhaul. It's long-winded and repetitive, particularly in the latter sections. Also, a better way to show the history of Mach (rather than writing it as a short story at the top) would be to display it in a table.

Also, am I alone in feeling that the article looks like it is going to come to some conclusion on whether or not Mach is a good thing? Reading through the article, I got the idea that the author had some sort of opinion, but it seems to flip-flop from criticising Mach for its IPC overhead through to enthusing about how the IPC bottleneck doesn't have to be that bad (e.g. for L4).

It's always read as a technical paper written by someone in the Mach community with it spending more time comparing Mach with other microkernels rather than just flatly describing Mach. This definitely requires fixing. --68.142.45.140 20:54, 16 May 2006 (UTC)

uname

Mach is said to be a UNIX kernel; can someone please edit its uname return-value into this article?--Jesdisciple (talk) 22:14, 13 March 2008 (UTC)

A description of Mach as just "a UNIX kernel" would be somewhat incomplete and misleading. There's a core Mach kernel, the kernel interfaces to which are described by the MACH Kernel Interface Manual, which provides (to quote the paper):

• basic message primitives and support facilities,
• port and port set management facilities,
• task and thread creation and management facilities,
• virtual memory management functions,
• operations on memory objects.

It does not implement, for example, any file systems or network protocols, nor does it implement any UNIX system calls. Of those, the paper only says:

In addition to the facilities provided directly by the kernel, MACH also provides for complete emulation of all 4.3bsd functions as described in the 4.3bsd manual. This emulation is completely transparent to user programs and requires no special libraries or other utilities. On all VAX hardware MACH is binary compatible with 4.3bsd.

In the original Mach, those were, I think, implemented by kernel-mode code that ran atop the Mach primitives; they could also have been implemented by, for example, user-mode servers making system calls that directly invoke Mach kernel primitives.

4.3BSD didn't even have uname, as I remember; uname came from the PWB/UNIX strain of UNIX, not the Research Unix strain, and BSD came more from the Research UNIX strain. As such, I doubt there was a "uname return-value" in the original Mach. (Eventually, uname made it into the BSDs, etc., for compatibility.)

A number of Unix-like systems were built atop Mach; the "Operating systems based on Mach" section of the article lists some of them. At least some of them had or have uname, but the output isn't the same between, for example, Mac OS X and DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX. I don't know whether NEXTSTEP had uname, but, if it did, its output wasn't the same as Mac OS X's output (OS X reports "Darwin" as the system name, but "Darwin" didn't exist, as such, before Apple bought NeXT).

In addition, some systems that weren't solely Unix-like, such as IBM Workplace OS, were built atop a (modified) Mach kernel; Workplace OS, according to the article, had a BSD personality, which might or might not have uname, but the MS-DOS and OS/2 personalities almost certainly didn't have uname, as the OSes they emulated didn't have uname.

So, unless the 4.3BSD-compatible Mach had uname - and, as indicated, I doubt it did - it's impossible for somebody to add its uname output to the article, as it didn't have uname output. Guy Harris (talk) 02:22, 14 March 2008 (UTC)

virtual memory management system

I found the quote:

The Mach virtual memory management system was also adopted by the BSD developers at CSRG

The problem I find with this quote is that there isn't enough information how Mach influenced today's BSD. Since Mach kernel is a microkernel, is the Mach's virtual management system really compatible to the monolithic BSD derivatives? I don't know but in the article there needs to be more clarification about the virtual memory management system in Mach and BSD. —Preceding unsigned comment added by Komitsuki (talk • contribs) 09:38, 4 June 2009 (UTC)

There's not much microkernelish about the lower layers of VM system - it has page fault handlers, data structures to represent address spaces and mappings, etc.. That's what was incorporated into 4.4BSD, with the topmost layer being based on BSD system calls such as mmap() (first implemented "for real" in SunOS 4.0, and later adopted by non-BSD-derived UN*Xes as well) rather on Mach-style APIs. Guy Harris (talk) 00:54, 3 December 2014 (UTC)

Mach is a structure monitoring cpu-memory access. So apparently it's the other way around, Mach was the one influenced by BSD/Unix/Plan9, casting any all machine part to BSD-file, for monitoring all machine parts. So by casting cpu-memory resources to more single monolithic file-like point, Mach kernel practically completed the picture that's been covered by BSD-process cast, syscall, and hive-minded humanity traitors. — Preceding unsigned comment added by Dyk408 (talk • contribs) 22:57, 2 December 2014 (UTC)

Mach in a 64-bit environment

This article mostly discusses the performance hit in a Mach microkernel due to context switching. However, it makes no mention of a 64-bit environment in which context switching should no longer be necessary (for example, Snow Leopard running a 64-bit kernel can accommodate 32-bit/64-bit user apps plus the 64-bit kernel w/o context switching). Here's a link since I can't explain this correctly: http://www.appleinsider.com/articles/08/09/04/road_to_snow_leopard_twice_the_ram_half_the_price_64_bits.html —Preceding unsigned comment added by 173.206.4.117 (talk) 12:32, 9 November 2009 (UTC)

If I understand, there is less PMMU context switching necessary as there is more address space and the kernel VM space can be mapped in the same address space. It does not mean no context switch, but a lighter context switch. This also does not solve the issue of syscalls where userland must trap (or use the special syscall instruction when available) for a switch to kernel/supervisor mode and stack. I guess that yes, some microkernel IPC designs could benefit from a larger address space in some circumstances to reduce the overhead. The overhead is still lower in a single unprotected address space though, as it was in AmigaOS (only need to switch messages among queues using node pointers). Now consider the following scenario, on PMMU isolated components: some user task invokes a file system operation, sending a message to a file system task, sending itself a message to a block layer I/O and strategy task, itself sending a message to a HD device task... each possibly expecting an error back, so using synchronous messages for which a reply is expected. You can probably understand the performance implications, comparatively to a syscall (a type of hardware-assisted synchronous message) on a monolithic-type kernel, with the internal operation consisting of direct function calls between all the internal layers (other than the interrupt service routines)... Darwin (the OSX kernel) can be considered to be a hybrid kernel, with a Mach layer and a more traditional monolithic layer (similarily to running a Linux kernel under an L4 task). These hybrid kernels can have components organized around a small microkernel, with the more complex systems provided by large tasks handling most other operations with less overhead. 76.10.128.192 (talk) 06:25, 1 July 2012 (UTC)

"Context switching" refers to switching from one running process to another. In any OS where each process has its own address space (which includes all the Mach-based UN*Xes), a context switch will involve an address space switch, whether it's in a 64-bit OS or not; 64-bitness doesn't change anything there. It does not refer to switching between 32-bit and 64-bit mode, or switching between user mode and kernel mode.

And the performance hit being referred to is for operations in which one process requests a service that's performed not in kernel mode in the same process, but in user mode in another process. There is a significant amount of that in OS X, but that's mostly for graphics operations and servers such as coreservicesd, configd, and so on. Network and file operations in OS X are done using the same system calls that are used in other BSD-flavored OSes, with the services performed by kernel-mode code in the same process. Guy Harris (talk) 01:39, 3 December 2014 (UTC)

And the speedup with a 64-bit kernel isn't eliminating context switches between processes, it's eliminating an address space switch within a process when making a system call or returning from a system call. The 32-bit Mac OS X kernel had a separate address space for kernel code and user code, so that user code could get a full 2^32-bit address space, which meant an address space switch when entering kernel mode from user mode or exiting kernel mode to go to user mode; the 64-bit kernel left the kernel in the same address space as user code (but not accessible to user code), so switching modes doesn't require an address-space switch. Switching between processes, however, still requires an address-space switch, even with a 64-bit kernel. Guy Harris (talk) 23:51, 12 August 2022 (UTC)

Copy on write?

The sentence This offered a new solution to the port concept, using the copy on write mechanism used by VM. is very confusing. The previous sentences uses VM for virtual memory, but copy on write is a function of the operating system rather than the MMU. From what OS did copy on write find its way into Mach?--Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:46, 12 July 2021 (UTC)

I read it as meaning the VM operating system, though I'm not familiar enough with its internals to know if it's a direct reference, just that VM pioneered a lot of stuff both in terms of virtual machines and virtual memory, especially with regard to efficiency (esp. compared to MVS, apparently...) --Vometia (talk) 19:35, 12 August 2022 (UTC)

I read it as meaning "virtual memory". I changed it to "virtual memory system" (not to be confused with VMS, which is one OS of many that have a virtual memory system), meaning both the hardware (MMU) and software (page fault/protection fault handling code) that implements virtual memory, speaking of "the copy on write mechanism provided by the virtual memory system" rather than "...used by...".

I.e., I don't think they're saying anything about the history of COW, they're just saying that the kernel can provide a COW mechanism in its virtual memory code, and that (plus mapping the same physical page into different address spaces) is what's being used by the Mach message system to transfer large blocks of data as part of a message. Guy Harris (talk) 20:19, 12 August 2022 (UTC)