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位置的機制，使得其擴充性大打折扣。