From: "H. Peter Anvin" <hpa@zytor.com>
To: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"Michael K. Johnson" <johnsonm@rpath.com>,
Justin Forbes <jmforbes@linuxtx.org>,
Jordan Hargrave <Jordan_Hargrave@dell.com>,
Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-acpi@vger.kernel.org
Subject: Re: [GIT PULL] x86 setup BIOS workarounds
Date: Thu, 02 Apr 2009 13:07:40 -0700 [thread overview]
Message-ID: <49D51B0C.3040307@zytor.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0904012357050.4657@localhost.localdomain>
Len Brown wrote:
>
> At the risk of rushing to the defense of the ACPI spec...
>
> This does not look like a backwards incompatible change to me.
>
> In ACPI 2.0, size of 20 is always returned, and it would
> be a Linux bug if we examined the undefined values after byte 19.
>
> In ACPI 3.0, byte 20 is now defined. So if the BIOS returns
> a size >= 21, we are permitted to examine byte 20.
>
> So I agree with the test above, but I do not agree with the comment.
>
If you look at the details of the ACPI spec, this flag is explicitly
specified so that the BIOS can always return a fixed number of entries.
Now, a clever BIOS could of course skip these entries if the OS only
requests 20 bytes -- but if it can do that, it could just equally well
have *always* skipped those entries! So the flag is useless.
However, the ACPI 3 spec is written so to actively lead people into
implement things this way, and given BIOS developer track records, they
would simply truncate the result to 20 bytes if the size passed in is
20. This, of course, means that it is now reporting an invalid entry,
without retaining the information that it is invalid...
-hpa
prev parent reply other threads:[~2009-04-02 20:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 17:14 [PATCH] mark %esi as clobbered in E820 BIOS call Michael K. Johnson
2009-03-28 11:20 ` Ingo Molnar
2009-03-28 19:18 ` H. Peter Anvin
2009-04-01 16:40 ` [GIT PULL] x86 setup BIOS workarounds H. Peter Anvin
2009-04-01 18:24 ` Linus Torvalds
2009-04-01 18:51 ` H. Peter Anvin
2009-04-02 4:26 ` Len Brown
2009-04-02 19:31 ` Linus Torvalds
2009-04-02 4:15 ` Len Brown
2009-04-02 20:07 ` H. Peter Anvin [this message]
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=49D51B0C.3040307@zytor.com \
--to=hpa@zytor.com \
--cc=Jordan_Hargrave@dell.com \
--cc=jmforbes@linuxtx.org \
--cc=johnsonm@rpath.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.org \
--cc=torvalds@linux-foundation.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