跳至內容

Linux相容核心

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
Linux相容核心
LUK 0.2.1 運行 Kingsoft Office
開發者Insigma Technology
首次發布2006年
目前版本1.0-rc2（2014年1月16日，​10年前​（2014-01-16））
原始碼庫
編輯維基數據鏈結
程式語言C
作業系統Unix-like
類型核心
許可協定GNU General Public License 版本2
網站www.longene.org

Linux相容核心（Linux Unified Kernel，亦稱 Longene），是一個二進制相容Windows和Linux應用軟體和裝置驅動程式的電腦作業系統核心。它試圖在Linux核心的基礎上利用Linux核心材料構建MS Windows核心功能模組從而擴充Linux核心的支援能力使之同時支援Linux和Windows的應用程式和裝置驅動。

相容核心主要以C語言編寫，以GNU通用公共許可證授權使用。雖然相容核心還處在初期開發階段，但許多Windows程式已經可以在其上執行。與其相反但類似概念的是 coLinux。coLinux 是在Windows上運行Linux應用軟體。

特性

[編輯]

相容核心專案在Linux核心的基礎上利用Linux核心材料構建一個Windows核心環境（包括行程管理、執行緒管理、對象管理、虛擬記憶體管理、同步、系統呼叫、系統序號產生器制和裝置驅動程式框架等Windows系統核心機制），形成一個新的核心，使Linux和Windows應用程式和裝置驅動程式能夠直接在其上執行。

相容核心不是Linux核心和Windows核心的簡單堆砌。為了防止相容核心變得臃腫，如果一個功能可以用利用ReactOS（Windows的開源仿製品）代碼實現，也可以利用Linux核心函式通過編程實現（ReactOS、Wine、NDISwrapper代碼作為參考），相容核心傾向採用後一種實現方法。

相容核心有兩套系統呼叫（syscalls）及其相應的系統呼叫表（syscall table）：一套為Windows系統呼叫，另一套為Linux系統呼叫。Windows應用程式通過軟中斷「int 0x2e」訪問系統呼叫表進行Windows系統呼叫。Linux應用軟體則通過軟中斷「int 0x80」訪問系統呼叫表進行Linux系統呼叫。

相容核心專案不計劃開發Windows和Linux的在使用者空間執行的庫檔案（.dll和.so檔案）。這些庫檔案由Wine專案（或MS Windows/ReactOS專案）和Linux專案提供。

在Linux核內空間實現Windows核心機制方案的優點

[編輯]
  • 開發快速。Linux核心已有成熟的CPU管理、主記憶體管理、磁碟管理和外圍硬體管理等功能模組及其實現函式。採用擴充Linux核心，通過嫁接（重新導向）或重用Linux核心相關功能函式等方法實現Windows核心功能的方案要比從零開始編碼實現Windows核心的方案要快很多。
  • 相容性好，效率高。在核內空間實現Windows核心機制比在核外實現能夠達到更大的相容性。相比在核外利用宿主作業系統的API來構建Windows的API，在核內空間可以利用細小的核心材料來實現Windows的API。因核心函式顆粒度比API小，其靈活性更大仿製能力更強因而能夠達到更好的相容性。另外，Windows行程、執行緒、系統呼叫等在核內執行能夠避免在核外執行帶來的使用者空間到核心切換額外的消耗，因而相比更有效率。在核內實現Windows核心機制與原生的Windows核心開發方法是一致的，能夠克服核外無法實現Windows某些功能的缺點。
  • 能夠實現Windows驅動。
  • 能夠使用全套MS Windows庫檔案。Linux和MS Windows庫檔案是通過軟中斷（Linux為「int 0x80」，MS Windows為「int 0x2e」）進入核內進行系統呼叫的。相容核心在核心開發能夠為之設定與Linux和MS Windows中斷號相同的兩套獨立的系統呼叫以最大程度相容MS Windows環境，使得MS Windows系統全套原生的使用者空間庫檔案（.dll）能夠在相容核心上執行。這給開發除錯帶來方便，也給計劃和已經轉向Linux系統的持有MS Windows使用許可證的機構和個人帶來好處。
  • 相容核心主要是在Linux的核心模組（LKMs）中實現的，這使它像應用程式的外掛程式一樣很容易載入和解除安裝。
  • 裁剪方便。實現Windows的API和驅動機制後，可以在不影響系統正常執行的情況下裁剪去除與Windows無關的Linux部分而只保留Windows功能，縮減體積以適應某些主記憶體較小的裝置。

開發

[編輯]

相容核心是由中國的浙大網新有限公司在2005年9月發起的自由軟體專案[1]。作為專案負責人，毛德操先生提出了專案的設想和和開發路線。他寫了一系列闡述具體實現相容核心的文章，這些文章的組譯為相容核心白皮書[2]。根據的相容核心白皮書，相容核心開發的主要工作是在Linux核心中實現「一個框架和兩個介面」：

  • 一個符合Windows裝置驅動程式的特徵和要求的框架，即Windows裝置驅動框架，使得可以把多個Windows裝置驅動模組裝入核心，並使這些模組間的關係和執行條件跟它們在Windows核心中時相同。
  • 一組由Windows核心匯出(Export)函式介面(見Windows DDK)定義的匯出函式。對於裝置驅動程式而言，這些函式就相當於由核心提供的庫函式。
  • Windows的系統呼叫介面。微軟並沒有公開它的系統呼叫介面，但是在「Windows NT/2000 Native API Reference」和其他資料中已經揭開了這個秘密。在Linux核心中實現Windows的系統呼叫介面，就相當於用組合語言來實現另一種高階語言。這是因為，在核心裡面，可以使用的「磚塊」就不再是宏觀的Linux系統呼叫，而是Linux的許多微觀的核心函式了。

相容核心專案的成果為Linux核心修補程式。相容核心的開發者期望這些修補程式最終融入Linux標準核心成為Linux核心標準的一部分。那樣擅長開發Windows應用程式和裝置驅動的開發者就可以很方便地為linux平台開發軟體或把他們的產品移植到linux平台。對於Windows軟體開發公司來說，只需要開發維護一個代碼庫就可以實現跨平台，這將降低軟體跨平台所帶來的成本，增加這些公司把產品移植到Linux平台的意願。這些公司與Linux使用者都將從相容核心專案直接受益。

開發策略和線路

[編輯]

相容核心採用漸進方式進行開發，它以已經能正常執行的Wine和NDISWrapper為開發始點，通過開發自身的Windows核心功能模組替換Wine中相應的功能模組來實現Windows系統呼叫相關功能；通過改造和擴充NDISWrapper來實現Windows裝置驅動框架；通過利用嫁接（重新導向）等方法實現Windows核心匯出函式。具體開發策略和線路[3] 如下：

  • Windows系統呼叫
相容核心以Wine為開發始點，相容核心開發在核內執行的核心功能模組來替代Wine中在使用者空間執行的功能模組，並通過對Wine打修補程式使Windows應用軟體轉而使用相容核心功能模組。即是：如果相容核心已經實現了該功能，則使用相容核心提供的功能；否則使用Wine提供的功能。每替換了一些Wine的功能模組，經除錯測試穩定後就可以發行一個相容核心版本。這個發行版本又是下一個版本的開發始點，周而復始直到把Wine的所有功能模組被相容核心模組替代。相容核心開發不限於替代Wine功能模組，Wine在使用者空間受技術限制不能實現的功能相容核心也要加以實現。
  • Windows裝置驅動框架
NDISWrapper已經在Linux核心中實現了一個WDM的雛形，而ReactOS則已有一個基本可以執行的Windows裝置驅動框架。相容核心將以NdisWrapper為開發始點，借鑑ReactOS的代碼對NdisWrapper進行改造和擴充以實現Windows裝置驅動框架。
  • Windows核心匯出函式
ReactOS和NdisWrapper已經有一個基本的Windows核心匯出函式集合。相容核心在這個基本集合的基礎上逐步實現的自身的Windows核心匯出函式。具體實現方法是如果Linux核心中有對應物的可以通過對映(重新導向)/嫁接(適配)的方法連接到Linux核心中的對應物上，小部分在Linux核心中沒有對應物則需要利用Linux核心材料加以實現。

歷史版本

[編輯]

一個早期的版本,unifiedkernel-2.6.13,於2006年2月15日發佈。該版本實現了Windows系統調用機制。[來源請求]

色彩 意義
紅 舊版本; 不支援
黃 舊版本; 仍支援
綠 當前版本
藍 未來版本
版本 發佈日期 更新
0.1.0 2006年4月30日
  • 移植kernel-win32
  • Windows系統調用機制基於"int 2e"
0.2.0 2006年12月31日
  • 實現了Windows的進程/執行緒建立
  • 執行部分Windows的APC機制
0.2.1 2008年2月4日
  • 實現了Windows的進程/執行緒管理
  • 虛擬主記憶體管理
  • 同步管理
  • 對象管理
  • 載入EXE功能
0.2.2 2008年10月31日
0.2.2-1 2008年12月17日
  • 修正錯誤
0.2.3 2009年2月12日
  • 移植Wine的註冊表管理機制
0.2.4 2009年5月22日
  • 移植wine的檔案管理系統
  • 實現了一些註冊管理的API
  • binary packages for popular distributions provided
0.2.4.1 2009年8月31日
0.3 2010年5月31日
  • 移植所有wineserver的功能到核心及擺脫wineserver
0.3.1 2011年2月28日
  • 支援非root使用者使用
  • 支援程式中文路徑
0.3.2 2011年6月8日
  • 支援wineconsole。Windows平台的console程式，像cmd.exe可以像這樣執行了：wineconsole cmd.exe
  • 改進了行程的建立方式，使得windows的native-app 和 wine的一些buitin-app可以互相建立了
1.0-rc1 2013年12月31日
  • 完全修改了整個架構，Longene不再需要核心修補程式
  • Longene終於支援了SMP
  • 安裝更方便，相容性更好，穩定性更強
1.0-rc2 2014年1月16日
  • 將wine升級到1.7.10版本
  • 解決普通使用者重新啟動後無法使用的問題
  • 解決若干檔案權限問題
  • 修改檔案載入方式
  • 其他若干BUG

現在和未來的開發

[編輯]

相容核心正在整合QEMU代碼以增加對ARM架構上直接執行Windows應用的x86架構二進制映像的支援。相容核心開發將有兩個分支。一個是1.0分支，這是針對x86架構上的跨作業系統相容。另一個是2.0分支，這是針對既跨作業系統又跨CPU架構的相容。1.0分支的進展也體現在2.0分支中。[4] 相容核心開發人員已經對Windows裝置驅動框架進行了討論，NidsWrapper的代碼移植到相容核心的工作已經開展。預計不久將進行實現Windows裝置驅動框架的開發工作

可利用的資源

[編輯]

相容核心不是從零開始編程的，它是在其他專案已有的代碼基礎上進行開發的。它對這些專案進行整合和再發展。相容核心專案可利用的資源包括Linux kernel、Reactos、Wine、kernel-win32和NDISwrapper等[5]，它們都是開源專案原始碼可以自由取得。

相容核心是基於Linux核心的。它在Linux可載入核心模組(LKMs)中實現它的功能。與ReactOS專案從零開始編碼實現Windows核心不同，相容核心是利用Linux核心中豐富的核心功能函式來實現Windows核心功能的。其實現Windows機制的主要途徑如下:
  1. Windows系統呼叫介面的實現——一些Windows的系統呼叫可以通過嫁接（重新導向）到適當的Linux系統呼叫或部分重用相應的Linux核心函式來實現,,另一些在Linux核心中沒有對應物的功能則需要使用Linux低階的核內函式來實現。
  2. Windows裝置驅動框架——-基本的裝置驅動框架對應著Win2k核心中的I/O管理，以及電源管理、隨插即用等機制，也涉及部分對象管理、系統組態、和安全管理方面的功能。。這個框架上面與有關檔案操作的系統呼叫(open()，close()，read()，write()，ioctl()等)相銜接，中間實現基於「IO請求包」IRP（IO Request Packet）的裝置驅動機制，下面則融入Linux核心的中斷回應/服務機制、包括「軟中斷」即bh函式的執行機制。主要包括裝置驅動程式的動態裝入和連接的開發和實現、IRP的生成和傳遞、以及裝置驅動程式的啟動、同步、和終結開發和實現、 將裝置驅動程式的中斷服務登記嫁接到Linux的中斷機制上，將裝置驅動程式所關心的Windows核心執行狀態對映到Linux核心的執行狀態上、 將裝置驅動程式的DPC請求嫁接到Linux的bh函式機制上。
  3. Windows的裝置驅動模組(.sys檔案)——微軟持有著作權的.sys檔案基本上是一些標準的、基本的、常用的外部裝置，包括磁碟、USB、圖形裝置、網路裝置等的裝置驅動模組。Linux實際上已經具備相應的功能，只是需要將Linux核心(包括裝置驅動模組)中的這些函式和資料結構與具體.sys的呼叫介面之間架起橋梁。但是也可能有一些微軟的.sys模組在Linux核心中找不到對應物，那就需要仿製了。
  4. Windows裝置驅動支撐介面——多數裝置驅動介面函式(以及資料結構)在Linux核心中都有對應物，需要做的就是把所需的支撐函式和資料結構通過對映(重新導向)/嫁接(適配)落實到相應的Linux核心函式和資料結構上，包括一些適配的工作。也有些函式在Linux核心中沒有較為接近的對應物，那就要用Linux核心中的各種素材加以搭建。
ReactOS是一個MS Windows核心的開源仿製品。與相容核心利用Linux核心材料構建Windows核心的開發路線不同，它是完全從零開始編碼製作Windows核心的。和相容核心一樣ReactOS只是一個核心，它依賴Wine專案的使用者空間庫檔案使整個系統能夠執行。相容核心參考ReactOS的代碼實現Windows核心的基本機制，包括行程/執行緒管理機制，主記憶體管理機制，驅動系統框架等。
Wine在使用者空間實現了一個把Windows程式對Windows API呼叫轉向Linux API呼叫的相容層，這個相容層還負有Windows核心的行程/執行緒管理等的職能。雖然Wine和相容核心均利用核心材料構建Windows API機制，但具體的實現方法是不同的，相容核心是在核心空間利用Linux核心的核內函式來實現的，而Wine利用的是宿主作業系統的API來實現。另外相容核心是在核內利用核心函式實現行程管理、執行緒管理、對象管理、虛擬記憶體管理、同步、系統呼叫、系統序號產生器制和裝置驅動程式框架等Windows基本機制的，而Wine是在使用者空間實現這些功能的。雖然相容核心採取的技術線路與Wine的不相同，但Wine的實現方法還是可以能為相容核心提供借鑑的，而Wine對Windows核心有關資料結構的研究成果則可以直接被相容核心利用。
Windows使用者空間庫檔案(.dll檔案)雖然不是核心的一部分，但它們是作業系統能夠執行應用軟體不可或缺的部分。Windows使用者空間庫檔案數量眾多，Wine專案花了大量的精力仿製了這些檔案。相容核心只實現Windows核心相關功能，它依賴Wine提供Windows使用者空間庫檔案。大多數Wine的dll檔案可以直接用在相容核心上。
相容核心已經實現行程/執行緒管理、對象管理、虛擬記憶體管理等功能，但還有部分功能沒有實現。在過渡時期，相容核心利用Wine來提供它還沒有實現的功能。
Kernel-Win32是一個試圖把Wine的部分模組移入Linux核心以提高Wine的執行效率的專案。相容核心利用(部分是重實現)kernel-win32專案代碼實現了相容核心的Windows系統呼叫機制。
NDISWrapper在Linux核心中實現了Windows核心的一些部件，包括NTOSKRNL API（一個基本的WDM控制器）和一系列諸如把Wireless/NDIS/USB/PnP等的Windows系統呼叫轉向Linux系統呼叫的封裝。NDISWrapper不限於執行NDIS驅動，只要WDM驅動不呼叫它還未實現的Windows系統呼叫也是可以執行的。因此可以認為NDISWrapper是一個WDM的雛形。相容核心可以參考NDISWrapper和ReactOS的WDM實現構建自己的WDM。

使用者

[編輯]
  • MagicLinux - MagicLinux是一個基於Red Hat Linux的中文Linux發行版。MagicLinux 2.1之相容核心衍生版是第一個內建相容核心的發行版，它包含相容核心0.2.2版本。[6]

硬體需求

[編輯]

相容核心最低的硬體需求是:

  • 128MB RAM
  • IDE或SATA 硬碟
  • VGA相容顯示卡
  • PS/2或USB鍵盤
  • PS/2或USB滑鼠

架構支援

[編輯]
  • IA-32 (支援中)
  • x86-64 (不支援, 計劃中)
  • 龍芯3 (不支援, 計劃中) -- Loongson 3是一種MIPS-64 64-bit構架的通用CPU，它計劃包含二百多條指令以便硬體仿真x86 CPU指令，從而使其能夠執行Windows。

參考資料

[編輯]
  1. ^ [1] （頁面存檔備份，存於網際網路檔案館） Linux相容核心專案正式啟動，中國工程院院士倪光南、開源軟體推進聯盟主席陸首群祝賀。
  2. ^ 兼容内核白皮书. [2008-11-30]. （原始內容存檔於2009-05-22）. 
  3. ^ 开发Linux兼容内核的策略与路线. （原始內容存檔於2010-04-05）. 
  4. ^ [2] （頁面存檔備份，存於網際網路檔案館）寫於龍井1.0發布之際
  5. ^ 兼容内核的三个重要源泉. （原始內容存檔於2010-04-05）. 
  6. ^ Magic Linux 2.1 released (Machine translation). [2009-03-13]. （原始內容存檔於2019-10-18）. 

外部連結

[編輯]

https://web.archive.org/web/20090224010114/http://www.longene.org/

取自「https://wikicn.playgoteam.workers.dev/w/index.php?title=Linux兼容内核&oldid=74532684」