The 4-bit values used to hold x86 boot loader IDs are near exhaustion.
As a result, I'm proposing an extension protocol and will implement it
in time for the next merge window unless there are objections.
The proposal will be as follows:
- The boot loader IDs (type_of_loader >> 4) E and F will be reserved:
E - extended IDs
F - special uses
F is consistent with the current use of FF for "unknown".
- If the boot loader ID is E, the current pad1 field at 0x226 is
repurposed as an extended loader ID. The reason to use the pad1 field
is that it is present in all headers since version 2.02. The boot
loader ID will simply be: ((extended ID + 0x10) << 4) + (version), where
(version) as before is (type_of_loader & 15). This is the value which
will be reported in /proc/sys/kernel/bootloader_type.
The biggest question is probably: is there a need/desire for an extended
version field, or is four bits enough for existing bootloader needs?
-hpa
* H. Peter Anvin <[email protected]> wrote:
> The 4-bit values used to hold x86 boot loader IDs are near exhaustion.
> As a result, I'm proposing an extension protocol and will implement it
> in time for the next merge window unless there are objections.
>
> The proposal will be as follows:
>
> - The boot loader IDs (type_of_loader >> 4) E and F will be reserved:
>
> E - extended IDs
> F - special uses
>
> F is consistent with the current use of FF for "unknown".
>
> - If the boot loader ID is E, the current pad1 field at 0x226 is
> repurposed as an extended loader ID. The reason to use the pad1 field
> is that it is present in all headers since version 2.02. The boot
> loader ID will simply be: ((extended ID + 0x10) << 4) + (version), where
> (version) as before is (type_of_loader & 15). This is the value which
> will be reported in /proc/sys/kernel/bootloader_type.
>
> The biggest question is probably: is there a need/desire for an extended
> version field, or is four bits enough for existing bootloader needs?
i think it's prudent to add an extension mechanism, regardless of demand.
Existing bootloader projects will be content with the IDs they already
have so they are unlikely to request new ones. Future bootloader projects
cannot request it because they dont exist yet. So there's no-one to talk
up.
Ingo
Ingo Molnar wrote:
>>
>> - If the boot loader ID is E, the current pad1 field at 0x226 is
>> repurposed as an extended loader ID. The reason to use the pad1 field
>> is that it is present in all headers since version 2.02. The boot
>> loader ID will simply be: ((extended ID + 0x10) << 4) + (version), where
>> (version) as before is (type_of_loader & 15). This is the value which
>> will be reported in /proc/sys/kernel/bootloader_type.
>>
>> The biggest question is probably: is there a need/desire for an extended
>> version field, or is four bits enough for existing bootloader needs?
>
> i think it's prudent to add an extension mechanism, regardless of demand.
> Existing bootloader projects will be content with the IDs they already
> have so they are unlikely to request new ones. Future bootloader projects
> cannot request it because they dont exist yet. So there's no-one to talk
> up.
>
Good point. If so, it probably makes most sense to split pad1 into two
one-byte fields; one for ID and one for version. The bootloader_type
will have to continue to be (ID << 4)+basic_version; we can presumably
add a bootloader_version file which can report a bigger ID.
Either that or we can expose the raw pad1 field as bootloader_exttype
and force any users to be aware of the field splits.
-hpa
H. Peter Anvin writes:
> The 4-bit values used to hold x86 boot loader IDs are near exhaustion.
> As a result, I'm proposing an extension protocol and will implement it
> in time for the next merge window unless there are objections.
>
> The proposal will be as follows:
>
> - The boot loader IDs (type_of_loader >> 4) E and F will be reserved:
>
> E - extended IDs
> F - special uses
>
> F is consistent with the current use of FF for "unknown".
>
> - If the boot loader ID is E, the current pad1 field at 0x226 is
> repurposed as an extended loader ID. The reason to use the pad1 field
> is that it is present in all headers since version 2.02. The boot
> loader ID will simply be: ((extended ID + 0x10) << 4) + (version), where
> (version) as before is (type_of_loader & 15). This is the value which
> will be reported in /proc/sys/kernel/bootloader_type.
>
> The biggest question is probably: is there a need/desire for an extended
> version field, or is four bits enough for existing bootloader needs?
Why do we need a boot loader id at all? The purpose of a boot loader,
whatever it may be, is to load the kernel according to certain protocols.
Once that's done, why would the kernel care who/what loaded it?
Mikael Pettersson wrote:
> Why do we need a boot loader id at all? The purpose of a boot loader,
> whatever it may be, is to load the kernel according to certain protocols.
> Once that's done, why would the kernel care who/what loaded it?
A couple of reasons...
a) Bugs happen. Sometimes bugs are latent, and we later find ourselves
in an unenviable position of not being able to work around a problem
unless we know that we were loaded by <loader X> with <problem Y>.
b) Distro installers or other distro components sometimes find this
useful.
-hpa