1.5 在启动的时候配置操作系统
通常我们需要在操作系统引导的时候给它一些配置信息。不过这份文档不涉及 Boot
Loader 是如何得到这些配置信息的，而只是给 Boot Loader 提供了一个标准的方法来把这些
配置信息传递给操作系统。
1.6 怎么使得开发操作系统变得更容易
我们应该能够很容易地创建 OS Image。理想地情况是 OS Image 可以是操作系统平台使
用的任意一种 32 位的可执行文件。我们应该可以使用 nm 或者 disassember 来像反汇编一个
普通可执行文件一样来反汇编 OS Image，我们不需要使用特定的工具来创建特定的 OS
Image。如果这意味需要在 Boot Loader 中多做一些事情，我们也认为是值得的，因为在 Boot
Loader 中所占用的内存在操作系统启动以后是可以被再次使用的，而操作系统所使用的内
存是需要一直占用的。操作系统不应该需要解决如何进入 32 位模式来 load 在 1M 内存以上
的操作系统数据问题，否则这会使得创建 OS Image 更加的困难。
不幸的是，可执行的文件格式非常多，即使是在类 Unix 的 PC 操作系统中也是很多的，
而这些格式在每个操作系统中都是不一样的。绝大部分自由操作系统使用 a.out 格式的变体，
不过他们中间的一些正在向 ELF 格式迁移。当然，Boot Loader 不需要能处理所有的可执行
文件来引导不同格式的 OS Image。否则，Boot Loader 就变成了一个特定的操作系统了。
这份规范在这个问题上做了一个折中，遵循多重引导规范的 OS Image 通常含有一个多
重引导头【见 3.1 节】，这个头使得 Boot Loader 可以引导操作系统而不需要知道操作系统使
用的 Image 文件是 a.out 格式还是其他格式。这个头不需要放在 OS Image 的一开始。因此，
操作系统既可以保持原来的文件格式又可以与多重引导兼容。
1.7 启动模块(Boot Modules)
现代的操作系统内核如 VSTa 和 Mach，并不是在内核中包含了所有的功能。它们启动
的时候需要其他的软件模块来完成访问设备，挂载文件系统等工作。当然这些模块也可以和
内核一起被嵌入到 OS Image 中。但是如果 Boot Loader 能够一开始就独立的引导这些模块
的话，对于操作系统和用户来说，会显得更灵活、空间效率更高以及更方便。
因此，这份规范应该给 Boot Loader 提供一个标准的方法，使得 Boot Loader 可以告诉
操作系统哪些模块已经被引导了，以及在哪里可以找到这些模块。Boot Loader 不是一定要
支持模块引导，但是我们强烈建议这样做。因为如果没有了这个功能，一些操作系统就不能
引导了。
2 文档中使用的术语
必须(must) ：
当描述 Boot Loader 和 OS Image 一定需要遵循的规则时候，我们使用术语必须。如果
他们不遵循这个规则，就不能称为兼容多重引导的。
应该(should) ：
当我们描述 Boot Loader 和 OS Image 推荐遵循的规则的时候，我们使用术语应该。当
然，他们也可以不遵从这些规则。
可以(may) ：
当我们在描述 Boot Loader 和 OS Image 被允许遵循的一个规则的时候，我们使用术语
可以。
Boot Loader：
4星 · 超过85%的资源 需积分: 29 165 浏览量
2008-03-02
17:53:20
上传
评论
收藏 160KB PDF 举报 
myheyj2018-07-29可仅供参考而已。
hiberhe2016-04-01非常好的参与资料!
