永远不会发生。此启动协议存在一些非常严重的设计错误,存在巨大的安全风险。
首先,stivale 内核有一个 ELF 标头,但不知何故您应该知道该标头无效;标头中没有任何东西暗示它不是有效的 SysV ABI 内核。在 Multiboot 中, 文件开头必须有一些魔法字节,以便您可以检测协议;stivale / stivale2 中没有类似的东西。(锚点对您没有帮助,因为它可能出现在文件中的*任何地方*, 因此实际上必须*搜索整个文件*以确保它与 stivale 不兼容。)
其次,它使用节;根据 ELF 规范(参见 第 46 页),节是可选的,加载器无需关心。 加载器使用执行视图,而不是链接视图。仅因为这个协议而实现节解析对任何加载器来说都是巨大的开销,因为系统资源通常已经很稀缺了。
第三,节头位于文件末尾。这意味着为了检测 stivale,您必须加载文件的开头,解析 ELF 头,然后加载文件的末尾并解析节头,然后从文件的中间某处加载以获取实际的标记列表。 这可能是最糟糕的解决方案。而且,再说一次,没有任何迹象表明加载器应该这样做,所以您必须对所有内核执行此操作才能发现内核不使用 stivale。 这也会减慢对*所有其他*启动协议的检测速度,这是不可接受的。
应用程序处理器会主动轮询标签列表,而内核可能会随时调用引导加载程序代码,这意味着您根本无法回收引导加载程序的内存,否则必然会崩溃。这违背了 Easyboot 的理念。
最糟糕的是,该协议要求引导加载程序将代码注入任何与 stivale 兼容的内核,然后以尽可能高的权限级别执行。是的,这有什么不对吗?
因为我拒绝将质量低劣的代码交给别人,所以 Easyboot 中不会提供任何 stivale 支持。如果您听从我的建议,任何业余操作系统开发人员都不应该为了个人利益使用它。