無需作業系統直接執行 Python 程式碼

Josh Triplett以一個“笑點”開始了他在PyCon 2015上的演講：移植Python使其無需作業系統執行：他和他的英特爾同事讓直譯器能夠在GRUB載入程式、BIOS或EFI系統上執行。連演講的休息時間也沒放過，他有很多有趣的要說的事情，還有許多讓人大開眼界的演示。

Python在Boot Loader上執行的最初想法是能夠測試硬體，像BIOS，可擴充套件韌體介面（EFI）以及高階配置和電源介面（ACPI），而無需去寫一些“一次性測試專案“程式集。傳統來說，英特爾已經寫了很多針對DOS（BIOS系統）或EFI系統的測試程式。無論是DOS還是EFI都不提供環境保護，這樣程式就能夠駐入在記憶體和硬體中去做他們所需的任何事情。

他不過是想用指令碼來寫測試程式碼而已，“因為這樣比較有趣”。他既不想寫太多的 C 語言程式碼，也不想像以前那樣用那個能計算 C-類 表示式的 GRUB shell。 其實, 他說，“C 程式碼寫的越少， 我就越輕鬆”。

隨著時間的推移, 移植到 GRUB 中的 Python 已經變成操控硬體的利器。它又把我們帶回到使用 PEEK 和 POKE 在 Commodore 64(or DOS) 上面操控硬體的美好時光。“那些事是現在的硬體裝置無法完成的”他說。

 

GRUB中的PYTHON

BIOS Implementation Test Suite(BITS)，正如其名，將會執行在多種韌體上的GRUB中：32位BIOS或32/64位EFI。他使用原始的GRUB或GRUB 2。基於標準的PYTHON直譯器(如CPython)，但是他道歉道：它使用PYTHON2.7。這個工具的目標受眾對這個版本的語言相當熟悉。如果不是這樣，他更喜歡在以後遷移到Python 3.

有一個“讀取-求值-輸出 迴圈” 互動環境[read-eval-print loop (REPL)]讓你完全訪問Python語言。它包括Tab完成，歷史記錄，和行編輯。一個標準庫的“大量碎片”已經被一直BITS上執行。最重要的是，這個專案已經新增了一些對平臺支援的模組：CPU,SMP(symmetric multi-processing),ACPI,EFI以及其他。INTEL已經建立了一個測試集以及 使用Python寫了使用以上模組的一些試探性的工具。

Triplett然後從幻燈片切換到了虛擬機器的GRUB中執行一個Python直譯器的提示介面。他輸入了兩句語句到直譯器來展示它支援列表解析和任意大的整數（如：bignums）。

要獲得一個python互動環境，GRUB需要呼叫一個單獨的函式：

它會處理所有REPL[讀取-執行-輸出 迴圈]，包括對輸入的解析和執行、行編輯等等。
這兩個引數簡單的表明了在哪裡獲取輸入 和 當發生異常時在traceback裡要輸出什麼來當做原始檔。但是想要能在GRUB裡呼叫那個函式還有一些工作要做。

因為不能使用來自於 Linux 主機的工具鏈和特性，這個專案不能像平常那樣安裝和配置 Python。對於 GRUB 來說，沒有 GNU 目標宣告（例如：用於交叉編譯的 cpu-vendor-od-triple）和目標標頭檔案可以使用。因此，BITS 將所有的 Python 原始檔新增到了 GRUB 的構件系統中。本質上說那僅僅是一些GRUB 新增 Python 所必需的 C 語言檔案。通常，autoconf 將建立 Python 構件程式中的apyconfig.h 檔案來說明哪些功能在平臺上存在。相反的，這個專案手動的建立 apyconfig.h 檔案大量“不，我沒有這個功能”的配置引數和一小撮“是”的條目。

許多在 pyconfig.h 檔案中被列出的功能是被（或不被）作業系統所提供的，但是在這種情況下是沒有作業系統的。Python 的確需要最低限度的一些支援功能，以及一些額外被配置的特性。這個專案需要去做的是提供任何被渴望而又不存在功能。

CPython 需要什麼

那麼，什麼情況下你真的需要執行 CPython？Triplett 提供的大量例項來證明什麼時候需要執行 CPython。有一些平常的檔案操作就需要了，比如說：使用 stat () 來確定一個路徑是否包含 __init__或是檔案中是否包含 __init__。增加 simpleisatty()（以位為單位，檔案描述符是少於三則返回 true）好比經歷一個 seek() 執行一樣。為了支援那些功能，不得不新增一個簡單的檔案描述符表，因為 GRUB 的檔案功能使用結構體指標，而不是描述符。

解析器把一個字元放回在輸入流的時候，Python 也需要使用 ungetc() 。而不是在新增一個字元緩衝區的時候使用，即新增”快速 hack”來尋找後一個字元。新增開放式編碼的 qsort() 時也一樣一樣要使用  ungetc()；GRUB 不任何支援排序。

GRUB還沒有支援的另一個方面是浮點運算。專案組發現了一個許可的浮點運算庫FDLIBM。它沒有使用任何浮點硬體加速，這在GRUB環境是非常有用的。這意味啊即使在韌體沒完全初始化浮點運算硬體時也能使用浮點運算。

在使用Python時，我們大量使用printf()和sprintf()。大部分情況，GRUB版本工作很好，但對“%%”（輸出一個”%“）這種特殊格式還不支援。事實證明，Python頻繁使用格式化的字串輸出。

在被發現和修復之前，怪異的BUG仍然存在。

這個工程還有一些效能問題需要解決。首先，啟動時間出乎意料的長。對硬體來說，這是十分痛苦的事情，但是在 CPU 的類比電路上也很糟糕（“我們不想花三天時間做引導”）。部分問題來自於 Python 的直譯器，每次它讀取一個資料的時候都要呼叫 usesungetc()。GRUB 沒有太多快取記憶體的磁碟，所以所有 I/O 埠直接訪問磁碟。

通過加入對 .pyc (Python 位元組程式碼)檔案格式的支援，這個工程能夠提前減少許多語法分析工作。主機的版本和 GRUB 的版本在同一時刻編譯，用於 Python 檔案在啟動時的編譯工作。

這做出了實質性的提升，但是由於stat()的原因，啟動時間仍然有些慢。他說在Linux系統上，stat()僅花費幾微秒的時間，但是BITS版本會花費幾毫秒。增加對zipimport的支援能讓工程把所有的.py檔案打包放入一個單一的ZIP檔案中來避免對stat()的呼叫。

這個工程希望做有歷史和tab自動補全的REPL（讀取﹣求值﹣輸出迴圈），但是一般獲得支援的方式是使用GUN的Readline library。這個庫由有終端裝置的POSIX（可移植作業系統介面）提供環境支援。開發者不想寫一個“C程式碼檔案”來支援它，所以他們用Python寫了一個讀取線支援來替代。CPython的PyOS_ReadlineFunctionPointer被稱為一個使用C語言API的新Python函式的C函式集合。

為了能夠使用其他的操作和多種的測試套件，仍迫切需要構建 GRUB 的動態選單。GRUB 已經為裝置提供了磁碟和檔案系統像磁碟分割槽和 CD 驅動器（例如：“(hd0)”,”(cd)”）因此 BITS 增加了一個的“(python)”裝置和一個工作起來像在 Linux 使用者空間的檔案系統（譯者注：打不開請加梯子）。因此 Python 程式碼能訪問任意的記憶體檔案，例如在 (python)/menu.cfg 下的選單配置檔案，“即使我們沒有寫更多的C程式碼”，Triplett 說道。

訪問硬體

既然目標是提供一個友好的測試硬體環境，Python 需要能夠訪問它。一個叫做“bits”的模組被新增進來提供訪問各種硬體的功能，例如：CPUID，特殊模組暫存器 (MSRs)，I/O 埠，和記憶體對映 I/O。他用幾行程式碼展示了這些能力。

他引入ctypes模組，以便在下一部分演示中“操作原始記憶體片”。對於那些想要深挖一些的人來說，幾乎所有演示都可以在這個YouTube視訊的演講中看到。cpuid()呼叫返回了CPU0的CPUID，他之後將其列印出來。他問：“這是不是很有趣？我們正從Python中得到處理器的暫存器資訊。” 接著，他使用Python來解釋這個結果：

三個暫存器包含描述處理器型別的識別符號。他使用ctypes模組中的型別，以字串的形式重新解釋這三個暫存器（按照之前的順序）的資訊，結果顯示為處理器型別。

Intel希望能夠測試高度並行化的系統，但GRUB只瞭解啟動了的CPU的資訊。所以BITS在系統中喚醒每個CPU，並把它們放入一個睡眠迴圈中，使用MWAIT（x86監視器等待指令）等待工作的到來。特定CPU有專門的喚醒函式和執行函式。

這個專案還準備用Python獲取ACPI的資訊和方法。這參考了ACPI元件架構 (ACPICA)的實現並把它加入BITS中。由於全部是C程式碼，所以增加了Python繫結。這一做法使得Python可以呼叫任意ACPI方法——只要先將引數轉換成ACPI型別並將結果轉成Python型別。他用了一個簡單的Python程式演示瞭如何將虛擬機器中所有裝置的硬體ID顯示出來:

Triplett聲稱他不會繼續深入講解BITS硬體探索的細節。他已經在其它演講中更加詳盡地解釋過了。

英特爾也希望系統能使用這個韌體而不是BIOS訪問EFI。這種副檔名義上是指一切在EFI中都是”協議“，每一個都包含了原生c語言函式呼叫。要做到這樣，通過libffi提供的外部函式介面被移植到GRUB並且新增了支援EFI呼叫轉換的功能。使用這種方式和Python c型別的模組（Python提供的c語言型別的介面和函式）允許直譯器訪問EFI。他僅使用Python演示了訪問EFI的方法：

訪問EFI後，允許Python使用EFI檔案協議去建立目錄和寫檔案到EFI檔案系統中。這是非常有幫助的，因為GRUB僅僅能夠讀檔案。不僅僅如此，存在著影像輸出協議(GOP)能夠讀寫螢幕內容。正如他所解釋的，幻燈片就是簡單的影像，事實上是通過在筆記本上BITS和EFI顯示出來的。在BITS的環境下，做出了這個幻燈片和demo，因此，事實來說，整個演示就是一個demo，他說這些話時周圍響起了掌聲。這樣做是不需要任何一行新的C語言程式碼的。

最後他儲存了認為最好的demo，並從EFI（可擴充套件韌體介面）GOP（畫面組）的幀緩衝區中作為Python啟動，當他敲完最後的幾行程式碼，很明顯機器開始識別了，計算並顯示了一個400×400大小的 Mandelbrot set（曼德布洛特集合）的灰度圖片。他對周圍鼓掌的人說：“在EFI圖形協議中僅用八行Python程式碼顯示了不規則圖形（Fractal）”。大約要15秒來繪出影像，有點慢，他說，那不是Python的問題，而是因為使用純軟體進行浮點運算了。

在談話最後，Triplett指出在BITS（後臺智慧傳輸服務）裡沒有中斷處理的鉤子函式（hook），但是這很容易就新增上的。他說，在像Mirage OS（和其它的“類似作業系統”）也能在BITS上新增Python程式碼，並且和這沒有多大區別。“待辦事件清單上的下一個有趣的專案”是新增Python繫結的EFI TCP網路協議和鉤子到Python的socket模組，看看能否在那樣的環境（BITS）下執行一個簡單的HTTP服務（SimpleHTTPServer）。這樣就能新增一個“網路REPL（web REPL）”到BITS環境了。