UEFI 随笔 010 — EDK2 的 NULL Lib 聚合模式

声明：个人笔记，概不负责

无责声明：里面许多概念，零帧起步。个人博客，随口而谈，不是教程，概不负责。

一、一般性问题

通常组织一组可扩展的代码，需要回答两个问题，
（1）如何标定个体？通常用一个 int 型常量（或 GUID，或 string，或没有标识）
（2）如何聚合？（数据结构？聚合方式、时机？使用方式？）

个体标识由于其常量特性，通常可以安全的到处复制，从而达到共享、交换目的。
常量复制是一切架构的基点——是的，无论多么花里胡哨的系统，这就是软件系统的『炁体源流』
聚合的方式、时机，五花八门。至少有两种：① 在代码构建时，静态聚合；② 在运行时，动态聚合。

《一人之下》——“术之尽头，炁体源流”

二、此情此景（NULL Lib 聚合模式）

EDK2 有一种，利用 LibraryClass 把代码聚合在一起的方法。（这是 EDK2 独有的，与 UEFI spec 无关）
这是一种（本质上的）动态聚合的手法。我称为 NULL Lib 聚合模式

已知：
（1）铁定事实，所谓 EDK2 的 LibraryClass 就是（被 EDK2 精心打扮的）平凡的 C Library 而已。
（2）简化认知，所谓 EDK2 的各种 Module 就是（被 EDK2 精心打扮的）平凡的 PE 可执行文件而已。

形式上动态聚合
（1）每一个 LibraryClass 都可以有个（被 EDK2 精心打扮的） Constructor 函数，
（2）这个 Constructor 会（被 EDK2 精心打扮地）在 Module 加载时调用。【奇点 1】
（3）所以，可以在 Constructor 这里，执行动态聚合代码，把个体注入到聚合数据结构。（本质上的，动态聚合）
（4）提醒：其实 LibraryClass 早已在 Module 链接时，融入到 Module 里了。

形式上静态聚合
（1）EDK2 会在 DSC 文件中，确定编译时、链接时的所有参数。
（2）通常 Module 会使用具名 LibraryClass 来指明依赖。
（3）而可扩展的代码结构，会使用无名的 NULL 来，开放式注入任意数量的 LibraryClass
（4）链接时，只有这些（用户选择的）NULL LibraryClass ，才会被融入到最终的 Module 中。

推论：
所以 NULL Lib 聚合模式，必然有以下特征
（1）在 LibraryClass 实现的 INF 文件中，必然有 CONSTRUCTOR 定义【奇点 2】
（2）在 DSC 中，聚合点 Module 那里，必然有（大量的） NULL LibraryClass 无名绑定

《让子弹飞》——“此情此景，恰如彼时彼刻”（原片没有，经典的错误记忆）

三、奇点连接

现在问题是，在【奇点 1】的地方，Module 怎么知道调用哪些 LibraryClass 的 Constructor 函数？
也就是讲，在【奇点 2】的地方，LibraryClass 怎么把自己定义的 Constructor 函数送到【奇点 1】处？（即聚合）

EDK2 对【奇点 2】的答案，暴力而又简单——使用 Python 脚本直接生成一个 C 函数，这个 C 代码里没有任何数据结构。
因为，但凡是通过 EDK2 的 INF 文件构建的 LibraryClasse 或 Module ，都会被暴力注入一对 AutoGen.h 与 AutoGen.c 文件。
所以，EDK2 可以从从容容地动任何手脚，这也算比较朴素的产生式编程吧。
那个所谓的“NULL Lib 聚合模式”，自然而然地溶解在“EDK2 精心打扮的 LibraryClass 机制中”

EDK2 对【奇点 1】的答案，则非常的手工——依赖码农的双手（如果将来 AI 没有灭掉码农的话）
每个 Module 都必须要有个（符合 PE 机制的？DXE 约定的？）入口函数。
我们在 INF 中指定的入口函数，其实不是真的入口，EDK2 会统一提供个 Wrapper 函数，作为真的入口函数。
在这个 Wrapper 函数里，EDK2 可以注入任何代码，我们自己提供的（自以为的）入口函数，其实只是 Wrapper 中的一行调用而已。
每个 Module 都必须在 INF 中选择自己的 Wrapper 函数，就是（码农徒手指定的）各种花式的 EntryPoint
// TODO, 最好弄个 call stack 出来