没有合适的资源?快使用搜索试试~ 我知道了~
首页《多重引导规范》(英文名:Multiboot Specification)
《多重引导规范》(英文名:Multiboot Specification)
4星 · 超过85%的资源 需积分: 29 29 下载量 9 浏览量
更新于2023-03-03
评论
收藏 160KB PDF 举报
免责声明:此资源来源于网络,其著作权属于与本书相关的单位或个人。在此仅供学习和交流使用,请在下载后24小时内删除。如果因此而引起相关法律问题,本人概不负责,谢谢合作。<br><br>经典著作《Multiboot Specification》的中文版《多重引导规范》,操作系统类的圣经级著作。<br>
资源详情
资源评论
资源推荐
多重引导规范(Multiboot Specification)
翻译:zyj001et (ncs dot mail.ustc.edu.cn)
翻译版本历史
版本记录 V 0.2
修改日期 2005-10-07
修改人 zyj001et(ncs dot mail.ustc.edu.cn)
修改内容 对照原文修改了V0.1版本中的不正确的地方
版本记录 V 0.1
创建日期 2005-6-6
创建人 zyj001et(ncs dot mail.ustc.edu.cn)
注意:该版本历史是本翻译文档的版本历史,而不是原文档。
版权信息
本翻译文档遵循 GNU/GPL,你可以自由的修改发布它
1 介绍
这一章粗略地介绍一下 Multiboot 地相关信息,注意,这不是规范本身的一部分。
1.1 Multiboot 规范的背景
每一个操作系统一般都有自己的 Boot Loader。在一个机器上安装一个新的操作系统通
常要安装一些全新的启动机制,而这些机制在安装时候和启动时候的用户接口都不同。如果
使用传统的 Chaining 机制来使多个操作系统在一台机器上友好相处,那么这是一件很痛苦
的事情。对于一个特定的操作系统来说,Boot Loader 方面我们通常是没有选择的余地的。
如果操作系统的 Boot Loader 不像你所希望的哪样,或者在你的机器这个 Boot Loader 根本
就不能正常运行,你就要很郁闷了。
对于已经存在的商业操作系统,我们不能解决这个问题,然而对于自由操作系统社区来
说,这不是很困难的事情,只需要大家碰到商量一下就可以了。这正是这份规范的目的。简
单的来说,它定义了 Boot Loader 和操作系统的一个接口,任何遵循这个规范的 Boot Loader
可以引导任何一个遵循这个规范的操作系统。这个规范不涉及 Boot Loader 是如何工作等方
面的内容,而只是定义了它们如何与要引导的操作系统进行交互。
1.2 适用的体系结构
这份规范主要是用在 PC 上,因为 PC 是目前最常见的架构,而且在 PC 上具有很多不
同的操作系统和不同的 Boot Loader。但是,其他的体系架构可能也需要一个引导规范,如
果在这个架构上还没有这样的规范的话,这份规范的很多方面,除去 X-86 架构特定的细节,
是可以适用到其他的架构上的。
1.3 适用的操作系统
规范适用的操作系统是自由的 32 位操作系统,它必须要能经过简单的修改就能支持这
份规范,而不是需要大的改动。这份规范最初是为 Linux、FreeBSD、NetBSD、Mach 以及
VSTa 设计的。我们希望新开发的自由操作系统从一开始就支持这份规范,从而可以利用已
经存在的 Boot Loader。当然如果商业操作系统支持这份规范也是非常好的一件事情,然而
这很可能是一个梦想。
1.4 启动的介质
我们可以写一个可以从很多介质如软盘、硬盘、网络引导 OS Image 的 Boot Loader。
基于硬盘的 Boot Loader 可能使用很多技术在硬盘上找到相应的 OS Image 以及要启动
的 Boot Module,比如通过解释特定的文件系统(如 BSD/Mach 的 Boot Loader),使用预先
定义的块列表(如 LILO),或者从一个特殊的 Boot 分区进行引导(如 OS/2)甚至从其他操
作系统中引导(如 VSTa 的引导代码是从 DOS 中引导操作系统的)。同样的,基于网络的引
导的 Boot Loader 可以使用很多不同的硬件以及协议。
我们希望 Boot Loader 应该支持多重引导机制来增强他们的灵活性、健壮性以及易使用
性。
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:
引导最终运行在机器上的操作系统的任何一个或者一系列的程序。Boot Loader 自身可
以包含许多阶段,但是这是具体的实现细节而不是本规范的一部分。只有
最后
一个阶段,
即将控制权从 Boot Loader 交给操作系统这一个阶段必须要遵循本规范中内容。只有这
样,它才是兼容多重引导的。
OS Image:
被 Boot Loader 引导到内存并且将控制权交于的第一个二进制印象文件。通常 OS Image
一个包括内核的可执行文件。
引导模块:
和内核一起被 Boot Loader 引导进入内存的其他辅助文件,当他们被调用的时候,除了
将他们的地址传递给操作系统以外,其他什么事情也不做。
兼容多重引导:
一个遵循这份文档中一些必须的规范的 Boot Loader 或者 OS Image 可以被称为兼容多
重引导的。这份文档中的应该和可以的规则,Boot Loader 或者 OS Image 可以不遵从。
U8:
8 位无符号数据。
U16:
16 位无符号数据。由于适用的目标架构是little-endian
1
,因此U16 是little-endian。
U32:
32 位无符号数据。由于适用的目标架构是 little-endian,因此 U32 是 little-endian。
U64:
64 位无符号数据。由于适用的目标架构是 little-endian,因此 U64 是 little-endian。
3 多重引导规范
规范中,主要阐述了 Boot Loader/OS Image 三个方面内容:
1. Boot Loader 看到的 OS Image 的格式。
2. 当 Boot Loader 启动一个操作系统时候的机器状态。
3. Boot Loader 传递给操作系统的信息格式。
3.1 OS Image 的格式
一个 OS Image 的格式可以是特定操作系统中的普通 32 位可执行文件的标准格式,当然
要除去这些可以被链接到非默认的引导地址如 PC 的 I/O 区域之上或者其他保留地址的文
件。当然,OS Image 是不能使用共享库以及其他的特性的。
一个OS Image除了含有表示它的格式的头之外,还必须含有一个额外的头,这个头叫做
多重引导头[Multiboot header]。多重引导头必须在OS Image的第一个 8192 字节之内,它还
必须是长字(32 位)对齐的。通常说来,它应该越早出现越好,它还可以被嵌入到正文段的开
始,即真正的可执行文件的头的后面
2
。
1
little-endian指数据的对齐方式。如 0X1234 存放在 0X00000000 开始的内存中,那么在 0X00000000 中存放
的是 0X34,而 0X00000001 存放的是 0X12。即高位高地址,低位地址。这个是X86 架构采取的方式。
2
比如OS Image的可执行文件格式是ELF,那么多重引导头可以嵌入到ELF头的后面,正文段的开头
剩余28页未读,继续阅读
erway
- 粉丝: 338
- 资源: 15
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- ExcelVBA中的Range和Cells用法说明.pdf
- 基于单片机的电梯控制模型设计.doc
- 主成分分析和因子分析.pptx
- 共享笔记服务系统论文.doc
- 基于数据治理体系的数据中台实践分享.pptx
- 变压器的铭牌和额定值.pptx
- 计算机网络课程设计报告--用winsock设计Ping应用程序.doc
- 高电压技术课件:第03章 液体和固体介质的电气特性.pdf
- Oracle商务智能精华介绍.pptx
- 基于单片机的输液滴速控制系统设计文档.doc
- dw考试题 5套.pdf
- 学生档案管理系统详细设计说明书.doc
- 操作系统PPT课件.pptx
- 智慧路边停车管理系统方案.pptx
- 【企业内控系列】企业内部控制之人力资源管理控制(17页).doc
- 温度传感器分类与特点.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论2