UEFI系统脚本语言与解释器研究与实现（可编辑）

UEFI系统脚本语言与解释器研究与实现（可编辑） UEFI系统脚本语言与解释器研究与实现 华中科技大学 硕士学位论文 UEFI系统脚本语言与解释器的研究与实现 姓名:陈庆 申请学位级别:硕士 专业:软件工程 指导教师:肖来元 2011-01 华 中 科 技 大 学 硕 士 学 位 论 文 摘 要 在统一可扩展固件接口 英文名 Unified Extensible Firmware Interface 或 UEFI[1] 的实现中，基本没有相应的脚本系统的支持，对于一个 UEFI 的开发者来说，编写 UEFI 可执行程序既费时又费力，这自然成了一个很大的不便，长远来看不利于 UEFI 快速的普及和发展。与此同时，UEFI 脚本语言的出现可以大大改善目前的现状。 通过对当前流行的脚本语言的归类和对比分析，出它们优点和缺点，同时 结合 UEFI 开发者面临的日常工作需求，来设计出了 UEFI 脚本语言的语法规则和内 在特性。简洁和易用是 UEFI 脚本语言的核心，为了达到这个目的，UEFI 脚本语言 将只变量区分为三种，并且涵盖了数组，输入，输出，和基本的条件控制语句和函 数调用等功能。即便如此，UEFI 脚本语言是足够可以解决我们 UEFI 开发者当前所 遇到的一些困难和麻烦。 一个可以工作的脚本系统的除了它自身语言语法的设计，同时也要包含其解释 器的设计和实现。其实解释器和编译器在很多方面都共同点，通过对编译原理的详 细研究和探讨，以及对 UEFI 编程环境的深入分析，UEFI 脚本解释器主要包含:词 法分析，语法分析，符号表，语法树等部分，它们当中的每一个在脚本解释的阶段 都起着非常重要的作用，因此这些部分便是 UEFI 脚本解释器的 关键和核心。 为了验证 UEFI 脚本系统的正确性和可工作性，按照 UEFI 所规定的语法，设计 出了一些测试用例，从测试的所得出的结果来说，基本上达到了UEFI 脚本解释器的 预期目标:可以有效的减少 UEFI 程序员的工作量;可以降低 UEFI 开发的门槛;可 以加速UEFI 的普及和发展。 关键词:统一可扩展固件接口 脚本语言 解释器 I 华 中 科 技 大 学 硕 士 学 位 论 文 Abstract In the Unified Extensible Firmware Interface implementation, there is very limited scripting support system, for developers it is a great inconvenience, it is not conducive to rapid spread UEFI’s development. At the same time, the emergence of UEFI scripting language can greatly improve the current situation. Based on comparative analysis and the classification the current popular scripting language, summing up their advantages and disadvantages, and combining with the UEFI developers daily work demand, to design the UEFI scripting language grammar rules and characteristics. Concise and easy using is core of UEFI scripting language. In order to achieve this goal, UEFI scripting languages has only three kinds of variables, and only cover the array input, output, and basic conditions control, and function calls etc. Even so, UEFI scripting languages are enough for UEFI developers to solve our current encountered difficulties and problems. A scripting system can work besides its grammatical design, also including the design and implementation of the interpreter. Actually interpreter and compilers are common in many aspects. Through detailed research and exploration, and analysis of UEFI programming environment, UEFI script interpreter, mainly includes: lexical analysis, grammar analysis, syntax analysis, the symbol table, every part plays a very important role in every stage of explanation, so these are the core of UEFI script interpreter. In order to verify the correctness and workability of the UEFI script system, according to specified grammar of UEFI, designing out some test cases. From the test result, it basically achieved the expected goal of UEFI script interpreter: to reduce the workload of UEFI programmers; reduce threshold of UEFI development: accelerate its development and popularization. Key words :Unified extensible firmware interface UEFI Scripting language Interpreter II 独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他 个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集 体，均已在文中以明确方式标明。本人完全意识到本声明的法律 结果由本人承担。 学位论文作者签名: 日期: 年 月 日 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即:学校有权 保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。 本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检 索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。 保密?， 在 年解密后适用本 授权书。 本论文属于 不保密?。 (请在以上方框内打“?”) 学位论文作者签名: 指导教师签名: 日期: 年 月 日 日期: 年 月 日 华 中 科 技 大 学 硕 士 学 位 论 文 1 绪论 1.1 课题来源与研究背景 本课题来源我在 Intel 公司实习期间，对该公司推出的下 一代 BIOS[2]，UEFI/EFI 系统的开发语言局限性思考之后，决定为它定制适合该系统的脚本语言。 UEFI 采用 C 语言语法，MakeFile[3]和微软 VC 编译器来开发。开发人员可以为 该系统开发硬件驱动，应用程序，组件等等。即便是一个“Hello, World ”程序，程 序员都要写上几十行代码加几个额外的配置文件(编译用)，而且要对系统的提供给 编程人员的接口要特别熟悉，否则将无从下手。这样的话，极大的降低了开发人员 的日常工作的效率，不利于UEFI 的迅速普及和发展。 这样，UEFI 脚本语言的出现，就减少开发者对 UEFI 系统的 API 过多的关注和 依赖，不必写复杂的配置，MakeFile 文件等工作。由于脚本易于学，易用的特点， 对于开发者来说，这样以来可以极大的提高他们工作效率，对于 UEFI 的发展也起到 了推动作用。 早在 90 年代中期，Intel 就因为传统的 PC BIOS 的存在的一些先天性的缺点: CPU16 启动模式、依赖 PC AT 的硬件、只能达到 1MB 寻址空间等问题，无法为大 型安腾服务器提供必要的支持时，进而提出了 Intel Boot Initiative 的项目，后来更名 EFI 。直到2007 年，Intel 将 EFI 标准的制定和修复的权力交给 UEFI 一个非营利性 的合作贸易组织，其委员会的委员包括AMD ，美国安迈，苹果，戴尔，惠普，IBM ， 超微，英特尔，联想，微软，凤凰科技十一个公司 管理，到了如今，UEFI 就是一 个可供开发商任意扩展的，有统一标准的固件接口规范，它采用很多当前比较流行 的系统开发技术，例如:它具有很多模块、生成最终文件的形式是以动态链接的方 式，它具有我们比较熟悉的堆栈方式来支撑这样一个系统。 即便为 UEFI 编写一个类似“hello world ”非常简单的UEFI 应用程序，都是非 常复杂和繁琐的，例如，你需要一个 inf 文件为其添加项目需要的各种配置，需要修 改该项目中 MakeFile 选项，需要了解 UEFI 的整个框架结构，系统调用。由于这么 1 华 中 科 技 大 学 硕 士 学 位 论 文 多的依赖，就需要开发人员通读 UEFI 系统的种类繁多文档，这样的就极大的降低了 开发人员的效率，所以针对 UEFI 系统的脚本语言的出现对他们来说是一种解脱，同 样也利于 UEFI 的快速发展。 脚本语言 Scripting language 是一种新兴的计算机编程语言，它也是一种能让开 发者比较快速的编写出让电脑听命行事的程序，它的原则是用简洁而又快速的方式 去完成某些复杂的事情，由于这项原则，使得脚本语言不论从入门或者到实际运用， 它都比 C/C++语言或 Java 之类的高级编程语言要更加容易。UEFI 脚本语言就是基于 这样一种思想来设计和实现的。 1.2 脚本语言的定义及产生意义 脚本语言是也一种编程语言，它不需要通常的编译步骤，它是解释运行的。目 前大多数可执行程序需要生成可执行文件后才能运行。与之相反的是，基于脚本语 言的程序是在解释的过程中运行的。在最早的阶段，脚本语言时常被大家称之为批 量处理语言或工作控制语言。 脚本语言的发明者在发明脚本语言的时候，目标是把编程按照基于组件的方法， 即与其为某个的可执行程序编写成非常多的代码，替代为一种将可执行程序分割成 足够小的, 它们各自都具备各自功能的，可以很多次的重复使用。这些小的模块小到 可以达到一些单独的可执行程序的要求，其余的每个部分都可在这些小的模块的基 础上产生。不同的模块有着很多不同的功能， 目的是让它们有着不同的用途，同时 可为被其它的可执行程序所利用。于此同时, 它必须要具备非常好的扩展性, 可以让 用户增添自己的功能。到了最后，终究需要用一种强的，比较灵活的东西把这些模 块“粘”合在一起, 使各个模块之间通信变得非常的快速和便捷。从上面的这个过程 来看，脚步语言的设计有如拼图游戏一样。 通常来说，脚本语言相对于大家熟知的高级或者低级的程序设计语言有下列的 特点和优势: 易学和易用:大多数脚本语言的对初学者来说，它本身需要开发者的技术背景 要求不是很高，这样一来，能够很快的找到合适的开发者。 2 华 中 科 技 大 学 硕 士 学 位 论 文 快速开发:脚本语言的原则归纳起来就是让“开发、部署、测试和调试”的周 期过程变得很短，很简洁。 动态的代码产生:脚本语言所产生的临时代码能够被及时的执行，这是一个非 常好的特性，在很多应用里面(例如 JavaScript 里的动态类型)是必需的。 易于部署:目前主流的脚本语言都可以被开发者随时随地的部署和分发，具有 很好的可移植性，而且不需要那么多时间去编译和打包。 1.3 脚本语言在国内外研究概况 回顾最近几十年科技的发展和革新，计算机发展尤其比其他产业来得迅速的， 很多的计算平台提供了数不胜数的系统编程和脚本语言。回顾在最开始的时候，第 一个出现的脚本语言的功能虽然简单而且能完成的工作也比较有限，它是一种被称 为作业的控制语言，这种语言在当时被大量的用于那个时代主流的操作系统中，它 当时的任务就是把工作按照有限级的顺序排好。在最近的 20 年内，即二十世纪八十 年代时 Linux 机器上，C 语言被贝尔实验室的开发者开发出来，它被用于 Unix 系统 级别的编程，而 SH，CSH 等壳编程被用于脚本语言的方面的开发。到了二十世纪九 十年代的时候，C/C++被用于系统编程，而 Visual Basic 等语言用于脚步的开发。在 现在这个以网络为主流的时代中，大家所熟知的 Java 语言被用于系统编程或者是 WEB 应用程序的开发，而像 JavaScript , Perl 和 Tcl 等语言被用于脚本的实践。 从第一个脚本语言的出现到现在，脚本语言其实已经在我们的视野里面已经存 在了相当长的时间，在最近几年中，有很多的要素的综合起来促使脚本语言的重要 性提高了很多层次，并且得到大规模的应用，效果也非常的不错。笔者觉得，其中 最重要的一个因素是由于基于网络的应用程序是在向胶着另外一个应用程序而前进 的。这种变换可以体现的几个例子就是用户图形界面，Internet 和 COM 框架的出现。 图形用户界面的出现在人们的视野的时候，大概在二十世纪八十年代的早些时 候，它来得直观，并且操作简单，所以在二十世纪八十年代后期得到很多公司的重 视。在许多系统级的编程项目中，用于图形界面的编程人力物力占了整个项目的一 半以上的比重。图形用户界面的编程的工作大多数是基于普通应用的，它的目的不 3 华 中 科 技 大 学 硕 士 学 位 论 文 是创建新的特性，新的功能，它所要做的是把视觉上的一些操作和应用程序内部逻 辑结构结合起来。一些流行的操作系统，例如大家熟知的 windows ，这些操作系统里 面都有很好的图形应用程序来展现屏幕的输出结果并隐藏其内部语言，从而设计者 不得不编写代码，因此这样一来一切都变得麻烦起来，例如为图形接口来提供内部 使用行为。目前来看，好的快速的开发图形界面环境大多数都是基于脚本语言，例 如大家熟知的 Visual Basic ，Hyperlard 和 Tcl/tk，我们可以想象，随着图形用户界面 的普及和发展，脚本语言也必然会越来越流行。 Internet 的迅速的发展也使脚本语言变得非常流行。Internet 其实只是一种粘合的 工具，它本身不用来创建任何新的计算和特性，它只是普通的把大量的目前有的事 物连在一起。因特网编程工作的具体的任务之一是把这些组件捆绑在一起工作，这 样脚本语言可以非常容易的得到应用。例如:Perl 编写的 CGI 脚本非常的流行， JavaScript 编写的网页非常的炫丽，从而也非常的流行。 脚本语言得到普及的另一个原因是脚本技术本身得到很大程度上的提高。像 Python 和 Perl 等脚本语言与 JCL 最开始发布的时候已经有了长足的进步和发展了。 例如，微软公司的 Visual Basic 其实不是真正意义上的脚本语 言:刚开始的时候，它 就是一个功能比较简单的系统或者称为高级程序设计语言，经过历史的演变，微软 公司对它进行了非常多的修改，才成为我们今天看到的这个样子。可以预测到，以 后新的脚本语言一定会将比现在的更好用。 我们不能忽视的另外一个因素是，计算机硬件的高速发展也让脚本语言运行起 来更快。在过去，用于系统程序设计语言在繁琐的应用程序中得到可接受时间的执 行。而在某些极端的情况下，系统程序设计语言似乎也不够高效，因此，有时不得 不用汇编语言来编程。然而相比之下，今天的机器比 80 年代的机器快几百倍，同时 仍以每 18 个月翻一倍的速度迅速增长。这样一来，机器本身就可以弥补脚本语言效 率低下的不足，非常多应用程序可以用来解释后再执行，同时保持着出色的执行结 果。例如，大家看到的 Tcl 脚本可以运行非常多的实例并且提供极佳的系统响应速度。 我们可以预测到，由于计算机硬件的不断提高，脚本技术将会越来越多，越来越广 泛的被应用于各种领域。 4 华 中 科 技 大 学 硕 士 学 位 论 文 1.4 论文的主要工作 本文主要从以下六个方面进行论述的: 第一章:简单介绍了本课题的研究背景、研究意义。 第二章:对 UEFI 编程环境及技术做一定的介绍。 第三章:对 UEFI 脚本语言做详细的分析与设计。 第四章:对 UEFI 脚本语言的解释器做详细的分析与设计。 第五章:对 UEFI 脚本系统做一定性能测试。 第六章:总结与展望，对全篇论文做了总结，探讨了以后 的努力方向。 5 华 中 科 技 大 学 硕 士 学 位 论 文 2 UEFI 编程环境的介绍 UEFI 在 NT32 环境模拟运行的界面效果图如图 2-1 所示。 图2-1 解释器运行环境的效果图 要开发一个 UEFI 脚本语言，必不可少的一个前提条件就是，我们得为其实现一 个属于它的脚本解释器，那么脚本解释器的实现就离不开 UEFI 自身的特殊的编程环 境，它跟我们平常接触的 windows 或者 Linux 大不一样。这一章大致的讲解几个特 别重要的概念，它们对于熟悉和掌握 UEFI 编程是非常关键和必要的。接下来就是分 别介绍这些非常重要的 UEFI 知识点，它们大致包括以下一些部分: (1)EFI System Table ; (2 )Handle database ; (3 )Protocols ; (4 )UEFI images ; (5 )Events and Task Priority Levels ; (6 )UEFI Driver Model 。 6 华 中 科 技 大 学 硕 士 学 位 论 文 2.1 EFI System Table EFI System Table 是UEFI 结构中最重要的数据。从这个数据结构，一个UEFI 的可 执行映像可以获取系统配置信息和一些丰富的系统服务，这些UEFI 服务包括下列项目: (1)EFI Boot Services ; (2 )EFI Runtime Services ; (3 )Protocol services 。 EFI Boot Services 和 EFI Runtime Services 分别通过 EFI Boot Service Table 和 EFI Runtime Service Table 来获得的，这两个 Table 都是 EFI System Table 其中的两个数据 域。EFI System Table 服务的数目和类型根据每个 UEFI Specification 版本不同而可 能不同。EFI Boot Service 和 EFI Runtime Service 在 UEFI2.0 Specification 中定义。 Protocol services 是一组相关的函数指针和数据域，并且以 GUID 命名的。Protocol [4] services 被应用于提供一些 devices 的软件抽象 ，例如 consoles, disks, networks 等等. 它们可以被用来为特定平台去扩展一些常见的 services。Protocol 是最基本的使 UEFI 固件保持可扩展性的模块。在UEFI2.0 中，它定义了超过30 种不同的 protocols ，各 种 UEFI 的实现可能会额外的去添加一些其它的protocols 去扩展它的功能。 它们的关系如图 2-2 所示。 图2-2 EFI System Table 示例图 7 华 中 科 技 大 学 硕 士 学 位 论 文 它的代码结构如下: typedef struct EFI_TABLE_HEADER Hdr; CHAR16 * FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; EFI_RUNTIME_SERVICES * RuntimeServices; EFI_BOOT_SERVICES* BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE * ConfigurationTable; EFI_SYSTEM_TABLE; 各个域的介绍如表 2-1 所示。 表 2-1 域的介绍 Member Description 它是 EFI System Table 的表头，其中它包括了 EFI_SYSTEM_TABLE_SIGNATURE 和 Hdr EFI_SYSTEM_TABLE_REVISION 和一个 EFI_SYSTEM_TABLE 大小的值以及一个 32 位 CRC 校正码 FirmwareVendor 指向一个包含 vendor 的字符串 FirmwareRevision 定义该 firmware 的版本号 ConsoleInHandle 激活状态的输入设备的句柄 ConIn 指向 SIMPLE_INPUT_PROTOCOL 接口的指针 ConsoleOutHandle 激活状态的输出设备的句柄 ConOut 指向 SIMPLE_TEXT_OUTPUT_PROTOCOL 接口的指针 StandardErrorHandle 激活状态的错误输出设备的句柄 StdErr 指向 SIMPLE_TEXT_OUTPUT_PROTOCOL 接口的指针 RuntimeServices 指向 RuntimeServices Table 的指针 BootServices 指向 BootServices Table 的指针 NumberOfTableEntries 内存中可控Table 的数目 ConfigurationTable 指向可控 Table 的指针 8 华 中 科 技 大 学 硕 士 学 位 论 文 2.2 Handle Database [5] Handle Database 是由一些句柄 和组成的，句柄则是由一个或多个协议的集 合，协议则是由一个 GUID 命名的数据结构，一个协议可能是空的，可能包含数据字段 可能包含服务字段，或可能包含服务和数据这两种字段。在平台 初始化，系统固件的 UEFI 标准驱动程序和应用程序将创建 UEFI 的句柄和将一个或多个协议附加到句柄中 去。在 Handle Database 里面的信息是全局的，可以被任何可执行 UEFI image 进行访问。 在 Handle Database 是 UEFI 固件维持对象的中央储存库。在Handle Database 是 由一些UEFI Handles 组成，每个 UEFI Handle 都有一个 GUID 区分，由系统固件进 行维护。句柄的数字提供了一个访问 Handle Database 条目的一个“钥匙”。Handle Database 每个条目是一个或多个协议的集合。该协议的类型，由 GUID 的命名，是 被附加到 UEFI Handle 中去决定该句柄类型。 UEFI Handle 可能是如下组件: (1)可执行映像，例如UEFI 的驱动程序[6]和 UEFI 的应用程序; (2 )设备，如网络控制器和硬盘驱动器分区; (3 )UEFI 的服务(驱动)，如EFI 压缩器和 EBC 的解释器。 图2-3 展示了一个 Handle Database 的模型，除了句柄和协议以外，一组对象是 与每个协议有关联。这个清单是用来跟踪哪些客户端去“消费”这些协议。此信息 对于 UEFI 的驱动程序的操作来说是至关重要的，因为这些信息是让UEFI 的驱动程 序被安全地装载，启动，停止，然后没有任何资源冲突。 First Handle Handle . . . GUID GUID Protocol Agent Handle Protocol Agent Handle Interface Controller Handle Interface Controller Handle Attributes Attributes Agent Handle Agent Handle Controller Handle Controller Handle Attributes Attributes Agent Handle Controller Handle Attributes Handle . . . GUID GUID GUID Protocol Agent Handle Protocol Protocol Interface Controller Handle Interface Interface Attributes . . . 图2-3 Handle Database 示例图 9 华 中 科 技 大 学 硕 士 学 位 论 文 2.3 Protocols 可扩展性是 UEFI 自身所固有的，在很大程度上， 它的这种特性是取决于 Protocols 。 UEFI 的驱动程序有时候会和UEFI 的Protocols 混淆。虽然他们是息息相 关的，他们是截然不同的。一个 UEFI 的驱动程序是一个可执行的并且安装好的UEFI 的映像，它安装了很多种类的Protocols ，以完成其工作。 UEFI 的Protocols 或是一个组函数指针和数据成员组成的，或者是一些 API ，但 它们是由规范定义的。至少，该规范将为一个 Protocols 定义一个 GUID 。这个数字 是该 Protocol 的真实姓名，将被用于检索Handle Database 。该Protocol 还包括一组典 型的程序或者数据结构[7] (称为协议接口结构)。以下是从第一个支持UEFI 2.0 规格 的 10.6 章的协议定义的例子。请注意，它定义了两个函数定义 和一个数据字段 GUID #define EFI_COMPONENT_NAME_PROTOCOL_GUID \ 0x107a772c,0xd5e1,0x11d4,0x9a,0x46,0x0,0x90,0x27,0x3f,0xc1,0x4d Protocol Interface Structure typedef struct _EFI_COMPONENT_NAME_PROTOCOL EFI_COMPONENT_NAME_GET_DRIVER_NAME GetDriverName; EFI_COMPONENT_ CONTROLLER_NAME GetControllerName; CHAR8 *SupportedLanguages; 图2-4 显示了单独一个 handle 和 Protocol ，它们只是Handle Database 里面的一部 分，并且它们是由 UEFI 的驱动程序产生的。该协议是由一个GUID 和协议接口结构组 成。很多时候，UEFI 的驱动程序，将产生一个额外的字段保持私有数据。该协议的界 面结构本身只包含指向该协议的功能。该协议的功能其实是包含在 UEFI 的驱动程序。 一个 UEFI 的驱动程序可能会产生一个协议或根据驱动程序的复杂性产生许多协议。 并非所有的协议都在 UEFI 2.0 中定义。在 EFI 开发工具包里面包括了一些协议， 是不是支持 UEFI 2.0 规范的一部分。这些协议是必要的，以 提供一个特定实现的功 能，但他们不是在支持 UEFI 2.0 规范定义的，因为它们不是 支持引导操作系统或写 一 UEFI 的驱动程序的必须。 10 华 中 科 技 大 学 硕 士 学 位 论 文 First Handle Handle . . . GUID Protocol Interface EFI Driver Function Pointer 1 GUID 1 Function Pointer 2 Function 1 . . . Private Data Access Device or Function 2 Services Produced by other EFI Drivers . . . GUID 2 . . . . . . . . . 图 2-4 Protocol 组成 示例图 UEFI 的可扩展性允许为平台设计添加自己的特殊协 议。这些协议可以用来扩大 这种需求，并提供对 UEFI 的一致性访问，提供设备和接口一致 性。 任何 UEFI 的驱动程序可以在启动时间来操作这些协议。但是，一旦 ExitBootServices ()被调用后，Handle Database 将不再可用。 一个 Handle 可能有多个 Protocols 被附属。但是，它们只能是同类型的协议。换 言之，一个单一的 Handle 可能不会产生一个以上的任何一个协议的实例。这可以防 止 Handle 有关的实例将被一个给定的请求消耗的恶意性行为。 2.4 UEFI images 本节将描述了 UEFI 不同类型的映像。所有的 UEFI 映像包含一个 PE / COFF[8] 标头，定义了其可执行代码格式。该代码可以在 IA - 32 的IA - 64，EBC 的，或x64 机器上运行。表头将确定处理器类型和映像类型。UEFI 2.0 定义了处理器的类型和 以下三个映像类型: (1)EFI 应用程序; (2 )EFI 启动服务的驱动程序; (3 )EFI 运行时驱动。 11 华 中 科 技 大 学 硕 士 学 位 论 文 UEFI 的映像的加载和装载到内存中去，是伴随启动服务中的gBS- LoadImage 一起的，包括以下几种支持的存储位置: (1)在PCI[9]扩展卡; (2 )系统光盘或系统闪存; (3 )如硬盘，软盘媒体设备，光盘，或DVD ; (4 )局域网服务器。 一般来说，UEFI 的映像不是被编译到一个特定的地址。相反，UEFI 的映象可 以被放置在 UEFI 系统内存中的任何地方。启动服务 gBS- LoadImage 执行以下操 作: (1)在内存中为UEFI 映像分配内存; (2 )生成适用于自动迁移内存映象; ( 3 ) 创 建 一 个 新 的 Handle Database ， 并 安 装 一 个 EFI_LOADED_IMAGE_PROTOCOL 的实例。 这个 EFI_LOADED_IMAGE_PROTOCOL 的实例包含有关UEFI 已加载的信息。 由于这些信息是在Handle Databse 中导出，它是提供给所有UEFI 的组成部分。 在UEFI 的映像被gBS- LoadImage 加载后，它可以gBS StartImage 调用。UEFI 的映像头包中包含的入口点是gBS StartImage 调用的地址。该调用点总是收到以下 两个参数: (1)映像的句柄; (2 )一个指向EFI System Table 的指针。 这两个参数分别用来做以下事情: (1)访问在这个平台上的所有的UEFI 服务; (2 )检索UEFI 的映像信息并加载并在内存中。 2.5 Events and Task Priority Levels 事件[10]是另一种被 UEFI 服务操作的对象。它们 可以被创建和销毁，它们要么 在等待的状态或有信号状态。一个 UEFI 的映像可以做下列任何 一个事情: 12 华 中 科 技 大 学 硕 士 学 位 论 文 (1)创建一个事件; (2 )销毁一个事件; (3 )检查是否在某个事件是否有信号; (4 )等待一个事件发生信号; (5 )要求一个事件从等待状态转移到有信号状态。 由于 UEFI 不支持中断，这就有可能对于那些习惯中断的程序员来说是一种挑 战。取而代之的是，UEFI 支持轮询的驱动程序。UEFI 的驱动程序最常见的使用是 使用一个计时器去定期轮询设备有没有加载。 以下三个因素都与每一个事件相关联: (1)事件优先等级; (2 )事件的通知; (3 )事件通知的背景。 事件的通知函数在事件状态被检查或当事件被再次等待的时候唤醒。事件通知 背景被传递到通知函数中去，并且被执行。TPL 是通知函数被执行的优先等级，一 般有 4 个优先等级，它们如表 2-2 所示。 表 2-2 EFI 中定义的事物优先级表 Task Priority Level Description TPL_APPLICATION UEFI 映象执行优先级 TPL_CALLBACK 回调等级 TPL_NOTIFY I/O 操作的优先级 TPL_HIGH_LEVEL 中断等级 2.6 UEFI Driver Model UEFI 2.0 规范定义了 UEFI 的驱动程序的模型。在UEFI 驱动程序模型后面的驱 动程序于 UEFI 应用程序共享同样的特性。然而，该模型可以让 UEFI 驱动控制更多 的驱动程序。表2-3 列出了 UEFI 的驱动程序模型相关Protocols ，它用于实现这种装 载和运行的分离。 13 华 中 科 技 大 学 硕 士 学 位 论 文 表 2-3 装载和启动/停止驱动程序的 Protocols Protocol Description Driver Binding Protocol 提供的函数的启动和停止驱动, 以及一个如何能处理某一特定 的控制器。特定的UEFI 驱动模型需要该协议。 Component Name Protocol 以条件来检索某个驱动的功能,形成易读的驱动控制器的管理。 在 UEFI 2.0 规格中该协议为选择性的。 Driver Diagnostics Protocol 执行诊断功能，在 UEFI 2.0 规则中这个协议选择性的, 。 Driver Configuration 提让用户配置的功能，以至驱动被管理。它也允许一个设备有 Protocol 默认的配置。在 UEFI 2.0 中这个协议是选择性的。 新的 Protocol 是注册在驱动程序中 Handle 里面。在 UEFI 的驱动程序模型中， 该驱动程序的入口时候的主要是安装协议并保证成功退出。在系统初始化后，UEFI 能用这些协议来操作这些驱动程序。 在 UEFI 的驱动程序模型定义了以下两个基本的UEFI 启动时驱动程序类型 (1)设备驱动程序; (2 )总线驱动程序。 一个驱动程序，同时具备设备驱动程序和总线驱动的特点，就是的一种混合驱 动。 2.7 本章小结 本章主要是阐述了UEFI 开发环境的一个框架，它主要包括 6 个重要的组成部分。 它们分别是 EFI System Table ，Handle database ，Protocols ，UEFI images ，Events and Task Priority Levels，UEFI Driver Model ，本章分别介绍了它们各自的特性，基本 构成和用途。这些都是 UEFI 可执行程序的最基本的数据结构或者编程概念，熟练掌 握它们对我们编写 UEFI 脚本解释器起决定性的作用。 14 华 中 科 技 大 学 硕 士 学 位 论 文 3 UEFI 脚本语言的分析与设计 在介绍了 UEFI 编程环境后，本章将重点介绍 UEFI 脚本语言的分析和详细设计。 3.1 编程语言特性分析 3.1.1 编程语言的特点 任何一种程序设计语言都有三个特点:具有完善的语法和规则、健全的词汇表、 解释词汇表的规范。 这些规范基本要涵盖以下几个部分: (1)数据和数据结构; (2 )指令及流程控制; (3 )引用机制和重用; (4 )设计哲学。 很多被广泛使用或者是经得起考验的语言，它们很多共同的特点，例如:拥有 负责标准化的组织，经常被修改来满足该语言的正式的规范，并集中讨论扩展或贯 彻现有已有的定义。 数据和数据结构 当今的计算机系统内部储存数据都是以两种元的形式来实现的，即开-关模式 on-off 。现实世界中表示信息的各种度量单位，像手机号、名字、度量以及类似的 较低端的二元数据，它们都经由编程人员设计好，整理好，把它抽象成为一种在计 算机中表示高级含义的概念。 在一个程序当中，有被用来针对处理信息的系统，我们将这种系统叫做编程语 言的型态系统[11] type system ;对于型态系统方面的一些讨论和发展趋势被称为型态 系统的理论 type theory 。编程语言可以被人为的分做类似静态的型态系统 statically typed systems ，例如 C++和 Java ，和动态型态系统[11] dynamically typed systems ， 例如 Python ，Visual basic ，Perl 和 Prolog 。前面的一些，它们也可以分为包含了声明 15 华 中 科 技 大 学 硕 士 学 位 论 文 和定义 manifest type [11] 的语言，意思就是每一个变量和函数的定义都要非常清楚地 被声明，不存在有第二种解释它的方法，同样它们有时被称为 type-inferred 语言。 非常多的编程语言可以在自身的声明的形态的前提上表达出更加有用的数据结 构形式例如:数组，列表，堆栈，文件等等。于此同时，面向对象语言[12](Object Oriented Language ，又译作“对象导向语言”)，这种新兴于二十世纪后期的一种程序设计语 言，它可以让编程人员自己去定义想要的数据形式，就是我们通常说的“对象” (objects )，和属于该对象自己的一些个函数(functions )或者称方法(methods )。 除了怎样去断定表达式和型态，这两者之间的种种联系，这就衍生了一个非常 重要的问题就是编程语言自己如何定义了这些型态，它们让哪些 型态充当表达式的 值。举个例子就是:像 C 语言这样的比较低级的语言，它们甚至允许编程者自己定 义内存区域和编译期的常量;ANSI C 甚至能让表达式返回自己定义过的一种数据结 构的值(struct values )。功能性的编程语言常常可以让变量自己去获得使用运行时得 出的计算结果，而不是获得该值的可能存在的内存地址。 指令及流程控制 一旦数据被确定下来的话，那么计算机要被指导去如何对这些相应的数据进行 一些处理，这里比较简单的一些指令可以使用关键字或者是定义好的语法结构来完 成，不同的程序设计语言利用一种串行关系来获取这些语句。于 此同时，在一个编 程语言中也有类似的语句达到控制和判读的功能，例如:分支、循环等等。 引用机制和重用 引用的核心思想就是必须有一种非常非直接的重定义储存空间的技巧，最常见 的一种方法就是通过对变量进行命名。依据语言的不同，从而引用能包括它指向另 外的储存地址的指针值，还有一种与它相同的方法就是对于一组关键词进行重新命 名。大多数编程语言使用了宏变量、引用或函数，类等等方法。它们的本质就是， 就是让替换后的名字可以使应用程序变得更加方便，并有极好的可重用性。 3.1.2 编程语言的分类 编程语言按照语言的等级，我们将它可以分为低级语言和高级语言。低级语言 又可以被分为机器语言[13]和汇编语言。 16 华 中 科 技 大 学 硕 士 学 位 论 文 (1)机器语言 计算机可执行程序是直接用能够被计算机识别的二进制代码指令进行读写的， 像这样的程序设计语言，我们称之为机器语言。机器语言通常是由计算机一次完成 一个最基本的操作指令来达到目的。机器语言是直接跟计算机硬打交道的，因此不 同CPU 型号的其他硬件的计算机，它们所采用的机器语言是不一样的，在这种情况 下，要让机器语言得到很多的推广和被人所接受是比较困难的。因此，在大多数情 况下，一般只有很少的一部分计算机专家或专业性比较强的工作人员才会使用这种 机器语言。举个例子，典型的机器语言程序如下: 1010 1111 0011 0111 0111 0110„等等几百个指令。 机器语言本身，它是一种特定计算机的自然语言，它和计算机的硬件的关系非 常大。机器语言只能在能读懂它的机器上运行。用机器语言进行编写程序，就是一 个从所有的 CPU 的指令系统中挑到合适的计算机指令，来组成一个个指令系列的一 种原始的过程。这种程序即便能被机器容易的理解和执行，但是相对于我们人类本 身来说，他们晦涩，不容易记住、非常难被理解、容易出错，通常专业人员才能掌 握它的特点，同时，程序员的写这样的程序，生产效率非常的低下，其质量非常不 容易得到保证。这种原始的手工方式与当今高速、自动工作的计算机非常的不相称。 (2 )汇编语言 汇编语言:用指令助记符、符号地址、标号等符号书写程序的语言。 它的出现，是为了克服上面所讲的机器语言，那些不容易读、 不容易编、不容 易记和容易出错的缺点，程序员用与代码指令含义非常近似的英文单词缩写、字母 或者数字等等符号来代替，机器指令代码，例如:用 SUB 表示运算符号“- ”的对应 的机器代码，这样就对应的产生了汇编语言。 所以说，汇编语言可以被解释为用一种比较容易记住的符号表示的针对机器的 低级的编程语言，汇编语言亦称符号语言。由于汇编语言是利用了帮助记忆的符号 名称来书写程序，比用最底层的二进制的机器语言来编程要容易些，在很大的程度 上缩短了编程的人力物力。汇编语言是用助记符代替了二进制代码的机器语言, 而且 17 华 中 科 技 大 学 硕 士 学 位 论 文 汇编语言的助记符与二进制指令代码一一对应，完全保持了二进制语言的简洁性。 用汇编语言开发程序相对于低级的机器语言来说，它的优点就是对计算机有较好控 制，而且也比较容易写出比较高质量高的程序。 由于在汇编语言中引入了助记符，所以当把汇编语言直接编写的程序输入到计 算机内，计算机不能以运行二进制机器代码那样来接识别并且执行它，为了能够解 释它，我们必须用汇编编译器对汇编的代码进行翻译组织，把它翻译成二进制代码 的时候，它才能被计算机运行。以一种可读，具有汇编语法规则 书写的文本文件称 为汇编源程序，在编译期时要将汇编源程序翻译为计算机目标程序。 目标程序一旦 被操作系统装载到内存里面去, 它就能被计算机顺序的执行。 汇编语言在宏观上如同二进制指令，是一组操作硬件的指令，所以它是面向机 器的过程语言，使用起来还是不是很方便和容易，可移植性不好，这是由汇编语言 是一种低级的语言形式决定。但是，汇编语言用编写出来的软件和系统，其经过汇 编编译器生成的目标文件占用资源少，CPU 指令是没有多余的，这些特点都是高级 编程望尘莫及的。 (3 )高级语言 至此为止，不管是二进制的机器代码还是汇编语言，它们都是针对特定计算机 的硬件的直接控制的，所以它们过于依赖机器的硬件，使用汇编的人必须对特定的 计算机硬件结构和其工作方式达到非常熟悉的地步，这样一来，对非计算机专业人 员是不太可能做到的，因此，这样的程序设计语言，对于程序语言的推广和发展是 非常的不利。随着计算机快速的发展，促使人们寻找那些与人类语言非相近的，同 时可以被计算机接受的，语法必须是无二义性的、规则要通俗的、比较直观的和容 易接受的程序设计语言。这种与人类自然语言非常近似的，且可以被计算机接受的， 和执行的计算机程序语言被我们称为高级语言。高级语言是针对开发者的比较容易 的一种语言形式。无论是什么类型的计算机，它们只要有其针对的高级语言的编译 或解释程序，用这种高级语言得出的可执行程序就可以被他们执行。到了现在，被 大家所熟知的高级编程语言有 C++、Java 、C# 以及Visual Basic 、Visual C++等。这 些程序设计语言都是属于系统的软件的一部分。 18 华 中 科 技 大 学 硕 士 学 位 论 文 计算机不能不经过转化而直接去运行高级语言书写的源程序，我们见到的源程 序必须在被计算机认懂之前，要通过编译程序去把高级语言转化 为能被计算机硬件 识别的目标文件，既我们常说的二进制目标文件。像这样的“翻译”通常有两种形 式，即编译后运行和边解释边运行。 编译形式其实就是:把一个称为编译器的程序，作为用户一个开发软件安装在 计算机操作系统里面，当用户把由高级语言编写的源程序导入到计算机以后，这个 编译程序便把源程序编译为能被该计算机识别的二进制目标代码，最后，计算机再 去执行该目标程序文件，最后得到结果。 相比之下，解释方式是:当源程序导入到计算机里面的时候，解释程序一边扫 描源程序，同时边解释，它会一个个的输入，然后逐句的翻译， 计算机同时去执行， 于编译形式最大的一个区别就是，解释程序一般不会有目标代码。Java 等高级程序 设计语言执行编译方式，而像 Python 这样的语言是通过解释方式来被系统执行的， 像 C++、C 等编程语言是能编写编译程序的高级编程语言。 每一种高级的编程语言， 它们都有自身的，事先定义的一些符号、英文词语、语义规范、语句结构的书写格 式。高级程序设计语言与人类能看懂的自然交流的语言(这里我们指的是英语 非常 的相似，很重要的一个方面就是，它们是与硬件不相关的，或者是隔离的，我们称 之为脱离了具体的计算系统 ，非常容易被广大程序员能掌握。高级编程语言的实用 性很不错，互容性也非常好，同时具有很好的可移植性。 现在，世界上每天都有非常多的高级语言的产生。这些高级程序设计语言都有 一个目的，那就是让程序员用非常容易能够被理解的方法来编写计算机程序，而且 又要满足足够精确而且简单的特点，让计算机能够识别。 高级语言的特点有很多特点，其中很重要的三部分如下: 简洁性:高级语言的每一个语句所能表达的意思都类似于低级语言或者机器语 言的非常多语句才表达的，当然，程序员现在只需花费更少的时间，去完成更多的 工作; 可移植性:高级语言是与机器的体系结构无关，在一台计算 机上运行的可执行 的程序只要稍微做点修改或根本不做任何修改，就可以在另一台计算机上来执行。 19 华 中 科 技 大 学 硕 士 学 位 论 文 程序员因此没有必要花费大量时间去了解使用计算机的内部体系结构，而是将精力 放在程序算法的设计和实现上，编写出更多的软件。 易读性:这对于需要维护和改进的程序是十分重要，高级程序设计语言可读性 再一步一步的增强，我们可以在日新变化的编程语言中看到。 3.1.3 现在流行的高级编程语言特点分析 到目前为止，可以大致将现在流行高级编程语言特性分为几 类: 1)强类型、弱类型 强类型语言与弱类型语言的之间比较明显。只要有隐式的类型转换的语言则是弱类 型的，例如 C 语言能将 char 隐式转换为 int 。不存在隐式转换的语言也是存在的，像 Haskell 一种函数式编程的语言 。在Haskell 里面，我们不能定义一个Double 类型的名字， 但是可以以整数作为名字，这是因为整数跟实数的类型是不同的，而且不存在隐式转换。 2 )过程式和面向对象式 过程式设计特点: (1)自上而下 top-down 的设计方式:是一个自顶向下，逐步来求的一种过程; (2 )以main 函数作为整个程序的中心，可以将main 函数分割成非常很小的模 块，每个模块可以一系列的子函数的调用组成; (3 )其主要的一个特征是以函数为单元来组织程序，程序中的数据就是更从函 数来的。 (4 )Main 里面的每一个子函数都可以被提炼成规模更小的子函数。重复这个过 程，那么就可完成一个过程式的设计; 过程式设计的优点:它能够容易被开发者学习和掌握，比较和人们直观的的思 维相似; 同时，过程式设计也有以下几个缺点: (1)数据是与逻辑分离开，对数据与操作的修改是很困难的; (2 )不能适应问题比较多，或者需求经常变化的情况; (3 )程序部分之间的依赖性太强了:Main 函数要依赖它的子模块，子模块又依 赖于更小的子函数; 20 华 中 科 技 大 学 硕 士 学 位 论 文 面向对象设计特点:面向对象编程以对象为中心，是对一系列相关对象的操纵， 发送消息给对象，由对象执行相应的操作并返回结果，强调的是对象。 [15] 3 )函数与闭包 凡是包含闭包这种形态的编程语言那么注定它是有函数这个功能的，目前为止 但是并不是所有的具有函数功能编程语言都有闭包，同样并不是所有的编程语言都 有函数。例如 Windows 的批处理文件就是不对函数支持的脚本语言。 那么闭包定义是什么呢,闭包就是可以使函数能够被上下文执行的一种指针。 举个例子: f