基于gnu-efi的EFI应用：唤醒映射配置选EFI变量还是配置文件？

一、EFI变量方案 #

• 优势：
  • 实现成本低：gnu-efi提供了直接操作EFI变量的API（比如uefi_call_wrapper(RuntimeServices->GetVariable, ...)和SetVariable），无需额外编写解析逻辑，工作量确实更小。
  • 系统原生支持：EFI变量是UEFI环境的标准特性，不用处理文件系统兼容性、路径解析等额外问题。
  • 访问效率高：变量存储在固件空间，读写速度快，适配小体量配置数据的场景。
• 劣势：
  • 易用性差：普通用户无法直接修改EFI变量，需借助bcdedit（Windows）、efivar（Linux）等工具，且部分固件可能限制变量的写入权限或大小。
  • 可读性弱：EFI变量存储二进制数据，需自定义格式（如键值对二进制结构），用户修改时不够直观。

二、配置文件方案 #

• 优势：
  • 易用性好：配置文件（如极简键值对文本）放在EFI分区的FAT32上，用户可直接挂载分区用文本编辑器修改，门槛低。
  • 扩展性强：文本格式支持注释、多组映射等，可读性和后期扩展能力远优于二进制变量。
• 劣势：
  • 实现成本高：因无法使用标准C库，需基于gnu-efi的SimpleFileSystemProtocol自行实现FAT32文件读写，以及简单的文本解析逻辑（如逐行读取、键值对分割）。不过这类逻辑复杂度不高，比如可写函数读取文件内容，按换行拆分、跳过注释行，再用=分割键值。
  • 依赖文件系统：需确保EFI分区为FAT32，还要处理文件不存在、路径错误等异常情况。

三、推荐方案 #

如果面向普通用户，优先选配置文件方案——虽初期要编写少量解析代码，但用户体验更好，后期维护也更灵活。可设计极简的文本格式，例如：

# 唤醒类型 -> 启动选项名称/GUID
0x01=Ubuntu
0x02=Windows Boot Manager

如果仅面向技术爱好者或自用，EFI变量方案更省事，可直接用二进制结构存储映射（比如每个条目用1字节存唤醒类型，后续跟着启动项的GUID或带长度前缀的字符串），通过自定义EFI变量名（如MyWakeupMap）存储数据。

内容的提问来源于stack exchange，提问作者KastenKlicker