MB2 spec: Endianness weirdness in definition of terms

[Hans Ulrich Niedermann]

The MB2 spec "definition of terms used through the specification"
defines terms like "must", "should", but also "u8", "u16", "u32", and
"u64":

> "u8"
>     The type of unsigned 8-bit data.
>
> "u16"
>     The type of unsigned 16-bit data.  Because the target architecture
>     is little-endian, u16 is coded in little-endian.
>
> "u32"
>     The type of unsigned 32-bit data.  Because the target architecture
>     is little-endian, u32 is coded in little-endian.
>
> "u64"
>     The type of unsigned 64-bit data.  Because the target architecture
>     is little-endian, u64 is coded in little-endian.

Does the sentence about the target architecture being LE, and thusly
the integer value being LE as well still make sense in Multiboot2?

To me this looks like a copy-and-paste error from the Multiboot1
specification.

The description of the MB2 header layout says that the values in the OS
image are in native endianness, not LE:

> 3.1.1 The layout of Multiboot2 header
> -------------------------------------
> 
> The layout of the Multiboot2 header must be as follows:
> 
> Offset  Type    Field Name     Note
> 0       u32     magic          required
> 4       u32     architecture   required
> 8       u32     header_length  required
> 12      u32     checksum       required
> 16-XX           tags           required
> 
>    The fields 'magic', 'architecture', 'header_length' and 'checksum'
> are defined in *note Header magic fields::, 'tags' are defined in
> *note Header tags::.  All fields are in native endianness.  On
> bi-endian platforms native-endianness means the endiannes OS image
> starts in.

And for the Boot Information, there appears to be no mention of
endianness for the values the bootloader gives to the OS image.

If we were to take the existing definitions of u16, u32, u64 seriously,
the values the bootloader gives to the OS image would be in little
endian, even if the OS image with the MB2 header is big endian.

That appears to be somewhere between weird and wrong. If weird, it
should be mentioned explicitly, and if wrong, it should be corrected.

AFAICT, the u16, u32, u64 definitions should be corrected to state
that those values are in native endianness (maybe unless specifically
stated otherwise).

I have to admit I have not checked whether the grub code actually
stores values for the OS image in little endian regardless of native
endianness. That would surprise me very much, though.

Uli