2 The definitions of terms used through the specification
- We use the term must, when any boot loader or OS image needs to
follow a rule — otherwise, the boot loader or OS image is not
- We use the term should, when any boot loader or OS image is
recommended to follow a rule, but it doesn't need to follow the rule.
- We use the term may, when any boot loader or OS image is allowed
to follow a rule.
- boot loader
- Whatever program or set of programs loads the image of the final
operating system to be run on the machine. The boot loader may itself
consist of several stages, but that is an implementation detail not
relevant to this specification. Only the final stage of the boot
loader — the stage that eventually transfers control to an operating
system — must follow the rules specified in this document in order
to be Multiboot-compliant; earlier boot loader stages may be
designed in whatever way is most convenient.
- OS image
- The initial binary image that a boot loader loads into memory and
transfers control to start an operating system. The OS image is
typically an executable containing the operating system kernel.
- boot module
- Other auxiliary files that a boot loader loads into memory along with
an OS image, but does not interpret in any way other than passing their
locations to the operating system when it is invoked.
- A boot loader or an OS image which follows the rules defined as
must is Multiboot-compliant. When this specification specifies a
rule as should or may, a Multiboot-complaint boot loader/OS
image doesn't need to follow the rule.
- The type of unsigned 8-bit data.
- The type of unsigned 16-bit data. Because the target architecture is
little-endian, u16 is coded in little-endian.
- The type of unsigned 32-bit data. Because the target architecture is
little-endian, u32 is coded in little-endian.
- The type of unsigned 64-bit data. Because the target architecture is
little-endian, u64 is coded in little-endian.