無需作業系統直接運行 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需要調用一個單獨的函數：

1	PyRun_InteractiveLoop(stdin, "<stdin>");

它會處理所有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 已經為裝置提供了磁碟和檔案系統像磁碟分割和 光碟機（例如：“(hd0)”,”(cd)”）因此 BITS 增加了一個的“(python)”裝置和一個工作起來像在 Linux 使用者空間的檔案系統（譯者註：打不開請加梯子）。因此 Python 代碼能訪問任意的記憶體檔案，例如在 (python)/menu.cfg 下的菜單設定檔，“即使我們沒有寫更多的C代碼”，Triplett 說道。

訪問硬體

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

12345

>>> import bits>>> from ctypes import *>>> c = bits.cpuid(0, 0)>>> ccpuid_result(eax=0x..., ebx=..., ecx=..., edx=...)

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

123	>>> buf = (c_uint32*3)(c.ebx, c.edx, c.ecx)>>> (c_char*12).from_buffer(buf).value‘GenuineIntel‘

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

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

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

12	>>> import acpi>>> print acpi.dump(‘_HID‘)

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

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

123456

>>> import efi>>> out = efi.system_table.ConOut.contents>>> out.ClearScreen(out)[ which clears the screen ]>>> out.OutputString(out, ‘Hello world!\r\n‘)Hello world!

訪問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環境了。

無需作業系統直接運行 Python 代碼