Mach
 |
| 原作者 | 卡內基梅隆大學 |
|---|---|
| 當前版本 | 3.0 |
| 類型 | 內核 |
| 網站 | http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html |
Mach（國際音標：[mʌk]）是一個由卡內基梅隆大學開發的計算機作業系統微內核，為了用於作業系統之研究，特別是在分布式與並行運算上。是最早實現微核心作業系統的例子之一，是許多其它相似的計畫的標準。
Mach開發計畫在卡內基梅隆大學從1985年運行到1994年，到Mach 3.0版結束。其他還有許多人繼續Mach的研究包括猶他大學的Mach 4 （頁面存檔備份，存於網際網路檔案館）。Mach的開發是為了取代BSD的UNIX核心，所以是許多新的作業系統的設計基礎。Mach的研究至今似乎是停止了，雖然有許多商業化作業系統，如NEXTSTEP與OPENSTEP，特別是Mac OS X（使用XNU核心）都是使用Mach或其衍生系統。Mach的虛擬內存（VM）系統也被BSD的開發者用於CSRG，並出現在BSD衍生的系統中，如FreeBSD。Mac OS X與FreeBSD並未保留Mach首倡的微核心結構，除了Mac OS X繼續提供微核心於內部處理通訊以及應用程式直接控制。
Mach繼承卡內基梅隆大學的Accent kernel，Mach計畫主導人理查德·拉希德曾於微軟的研究部門擔任高級人員，後成為微軟副總裁。另一Mach開發者阿瓦德斯·特凡尼安（Avie Tevanian）曾是NeXT首席程式設計師，之後擔任蘋果電腦軟體技術部門主管直到2006年[1] （頁面存檔備份，存於網際網路檔案館） 。
一個名為GNU Mach的計劃與其相關，它是GNU操作系統工程的一部分。已有的操作系統Debian GNU/Hurd便是基於GNU Mach及其上的GNU Hurd。
歷史
[編輯]名稱起源
[編輯]Mach概念
[編輯]Mach是作為傳統UNIX內核的替代品出現的，因此其間的不同之處值得留意。當時的人們已漸漸感受到了早期UNIX中「一切皆文件」的抽象機制的不足，有限的擴展性使得開發者捉襟掣肘，苦不堪言。雖說貝爾實驗室的Plan9在此方向上做了進一步努力，可是效果並不理想。現代操作系統需要更進一步的抽象。
比如UNIX的管道可謂飽受爭議。人們迫切需要一個類似管道的機制，允許在程序間交換不同的數據，而不僅僅是文件式的讀寫。或者換句話說，一套進程間通信機制（IPC）。一時間各路系統（包括UNIX）紛紛推出了各自的IPC機制，然而大多皆是些針對特定目標的庫，其通用性仍遠遠不夠。
鑑於此，卡耐基梅隆大學從Accent內核項目出發，嘗試開發了一套基於共享內存的IPC系統。Accent是一個擁有豐富特性的純實驗系統，不過在Accent開發期間，社會上研究操作系統的重點已經有所變化；且UNIX已經被廣泛接受作為研究的默認系統，Accent對UNIX的不兼容也限制了它在研究方向上的應用；更甚者，Accent的可移植性似乎並不是很好，而在當時看來（八十年代初）硬件平台的更新換代值正欣欣向榮，似乎會出現一次大爆炸。
因此卡內基梅隆大學轉向了Mach項目，其設計目標大體即一個結構清晰、UNIX兼容、高度可移植的Accent。按以下幾個概念作為其基礎：
- 「任務」即擁有一組系統資源的對象，允許「線程」在其中執行。
- 「線程」是執行的基本單位，擁有一個任務的上下文，並且共享任務中的資源。
- 「port」是任務間通訊的一組受保護的消息隊列；任務可以對任何port發送或接收數據。
- 「消息」是某些有類型的數據對象的集合，它們只可以發送至port - 而非某特定任務或線程。
Mach繼承了Accent IPC的理念，然其本身卻紮根於UNIX，輕而易舉即可移植UNIX下的程序。Mach引入了port的概念用以表示雙向的IPC，它就像UNIX下的文件一樣擁有權限信息，使得其安全模型非常接近UNIX。並且，Mach使得任何進程都可以擁有一般系統中內核才有的權限，從而允許用戶進程實現與硬件交互等操作。
同UNIX一樣，Mach系統也包含了一組豐富的實用工具，並保留了unix中驅動程序的概念用以硬件交互。
與UNIX的一大區別即在於，除了操作文件，Mach更可以操作一切「任務」。這一來大量的內核代碼可以轉移到用戶空間，使內核變得更小，從此領發了微內核的思潮。與傳統的系統不同，Mach下的進程（或者說「任務」）之下是多個線程。這在今天自己屢見不鮮，可是要知道，Mach正是如此定義任務與線程關係的第一人。內核的責任從總攬大局者精簡為基礎設施的提供者，並為其提供有限的調度。
Port機制在IPC中的應用該是Mach與其他傳統內核的一大分野。在UNIX下，用戶進程調用內核只能通過系統調用或陷入（trap）。用戶進程使用一個庫安排好數據的位置，然後軟件觸發一個中斷，內核在初始化時會為所有中斷設置handler，因此程序觸發中斷的時候，控制權就轉移到了內核，在一些必要的檢查之後即可得以進一步操作。
在Mach下，這就交給了IPC系統。與直接系統調用不同，這裡的用戶進程是先向內核申請一個port的訪問許可，然後利用IPC機制向這個port發送消息。雖說發送消息的操作同樣是系統調用，但Mach內核的工作形式有些不同——handler的工作可以交由其他進程實現。
IPC消息傳遞機制的應用為線程和並發提供了很好的支持。進程之下是多個線程，線程作為IPC機制的單元，Mach得以在消息被處理時控制線程睡眠或喚醒。這就允許系統將進程分布於多個處理器之上，消息直接通過共享內存實現也可，必要時為其它處理器複製一份也可。在傳統內核中這很難實現：系統必須保證不同處理器上的的不同程序不會在同時訪問同一塊內存，在Mach中則要更容易的多。不同進程的內存訪問互不干涉，一切交由port通信。
早期的IPC系統有些性能問題，必須正視。同其前輩Accent一樣，Mach使用一個共享內存機制以避免消息傳遞中低效的內存拷貝。它利用硬件的MMU實現數據共享，只在數據被修改的時候才執行拷貝，即寫時複製。
內核也必須檢查消息的正確性。Port在設計上即取了UNIX文件系統的概念，這一來就允許用戶使用現成的文件系統概念即可，權限、訪問許可之類就都有了。
這樣設計也簡化了開發。傳統的程序依然可以拿來，也可以再設計。單內核系統的一個bug就得讓整個系統崩潰從而不得不重啟，而Mach僅僅需要重新運行出問題的那個進程。操作系統即一組程序的集合，用戶得以選擇其系統的功能——只需管理當前運行的進程即可。
需要了解，Mach以上的所有特性皆為跨平台而設計。如下引用一段：
與UNIX最初無視多處理器的設計不同，Mach在設計伊始即將多處理器支持納入考慮。它的擴展性也很好，UMA還是NUMA都能很好的支持。Mach是為千種不同的處理器而設計的，移植到其他體系結構很容易。其設計的一個關鍵目標即為各不相同的硬件平台上，實現可移植的分布式系統。（Appendix B, Operating System Concepts）
不足自然也不少。相對容易的一個問題是port的位置不明顯，在UNIX下這樣的問題通過文件系統提供一個大家都知道的名字來解決。雖說這一機制也可以拿來，但是Mach在設計上又恰恰盡力使得port保持透明。缺乏表示port位置的機制，使得其擴展性大打折扣。