All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.