From: "H. Peter Anvin" <hpa@zytor.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>, x86@kernel.org
Subject: Re: RFC: running out of x86 boot loader IDs
Date: Thu, 29 Jan 2009 15:19:41 -0800 [thread overview]
Message-ID: <4982398D.1020506@zytor.com> (raw)
In-Reply-To: <20090129231641.GC29611@elte.hu>
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
next prev parent reply other threads:[~2009-01-29 23:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-29 23:06 RFC: running out of x86 boot loader IDs H. Peter Anvin
2009-01-29 23:16 ` Ingo Molnar
2009-01-29 23:19 ` H. Peter Anvin [this message]
2009-01-30 0:33 ` Mikael Pettersson
2009-01-30 0:38 ` H. Peter Anvin
2009-05-08 0:18 ` [tip:x86/kbuild-phys] x86: add extension fields for bootloader type and version tip-bot for H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4982398D.1020506@zytor.com \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.