无需操作系统直接运行 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 的文件功能使用结构体指针，而不是描述符。