Next: Specification, Previous: Overview, Up: Top [Contents][Index]
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 Multiboot-compliant.
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.
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.
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.
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.
Next: Specification, Previous: Overview, Up: Top [Contents][Index]