Messages in this thread |  | | | Date | Thu, 29 Jan 2009 15:19:41 -0800 | | From | "H. Peter Anvin" <> | | Subject | Re: RFC: running out of x86 boot loader IDs |
| |
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
|  |