From: "H. Peter Anvin" <hpa@zytor.com>
To: huang ying <huang.ying.caritas@gmail.com>
Cc: Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, ebiederm@xmission.com
Subject: Re: [PATCH 5/5] x86_64 EFI support -v3: EFI document
Date: Thu, 09 Aug 2007 09:29:05 -0700 [thread overview]
Message-ID: <46BB40D1.1050109@zytor.com> (raw)
In-Reply-To: <851fc09e0708090709s4f4fbbf9r91a7300a773f985a@mail.gmail.com>
huang ying wrote:
>
> I think at least the following should be done to make it a external
> boot protocol.
>
> 1. A version number field should be added.
> 2. The pointers (especially these come from firmware) should be 64bit
> to make the entry point can be used for both 32bit and 64bit platform.
> 3. More complete and formal document.
>
> Can you kindly tell me what's more should be done?
>
I have been looking at this recently, and also found that we already
have to make unacceptable compromises in order to fit into 4K, which is
set completely arbitrary (once upon a time, it was recycled as the
zeropage, but that is ancient history.)
Part of a formalizing the 32-bit/64-bit entrypoint involves a clean way
to extend this data set.
I mentioned in private email to a few people that I think a linked list
of tagged data items (similar to the way PCI capabilities work) would
probably make sense; we want a piece of code to know the structure
without needing to know the contents, in order to rescue data.
It's worth realizing that this is inherently never going to be as stable
as the real-mode entrypoint, and there is always going to be more
catch-up, simply because it's a broader interface. What is blatantly
clear, however, is that the current structure is utterly ad hoc and has
been totally prematurely adopted as some sort of standard interface.
Since I've spent time formalizing the structure over the last few months
I've been rather horrified; it is truly as bad as you could get.
So, anyway, this has popped up on my radar already; it needs to happen
anyway so let's get the discussion started.
-hpa
next prev parent reply other threads:[~2007-08-09 16:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 9:47 [PATCH 5/5] x86_64 EFI support -v3: EFI document Etienne Lorrain
2007-08-09 10:51 ` Andi Kleen
2007-08-09 11:23 ` RE : " Etienne Lorrain
2007-08-09 14:09 ` huang ying
2007-08-09 16:29 ` H. Peter Anvin [this message]
2007-08-09 17:01 ` Andi Kleen
2007-08-09 17:25 ` H. Peter Anvin
2007-08-10 13:03 ` Huang, Ying
-- strict thread matches above, loose matches on Subject: below --
2007-07-31 3:13 Huang, Ying
2007-07-31 4:40 ` Eric W. Biederman
2007-07-31 6:58 ` Huang, Ying
2007-08-01 17:16 ` Eric W. Biederman
2007-08-07 9:29 ` Huang, Ying
2007-08-07 9:54 ` Andi Kleen
2007-08-08 8:18 ` Huang, Ying
2007-08-08 10:08 ` Andi Kleen
2007-08-08 13:46 ` Huang, Ying
2007-08-08 14:09 ` Andi Kleen
2007-08-08 15:11 ` huang ying
2007-08-08 16:23 ` Andi Kleen
2007-08-08 16:10 ` Eric W. Biederman
2007-08-08 16:22 ` Andi Kleen
2007-08-08 17:17 ` Eric W. Biederman
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=46BB40D1.1050109@zytor.com \
--to=hpa@zytor.com \
--cc=ak@suse.de \
--cc=ebiederm@xmission.com \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox