From: ebiederm@xmission.com (Eric W. Biederman)
To: Huang Ying <ying.huang@intel.com>
Cc: "Tang\, Feng" <feng.tang@intel.com>,
Bjorn Helgaas <bjorn.helgaas@hp.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: EFI runtime-services on x86_64
Date: Tue, 03 Aug 2010 14:45:33 -0700 [thread overview]
Message-ID: <m14ofbgyki.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1280716920.2771.1519.camel@yhuang-dev> (Huang Ying's message of "Mon\, 02 Aug 2010 10\:42\:00 +0800")
Huang Ying <ying.huang@intel.com> writes:
> Hi, Bjorn,
>
> On Mon, 2010-08-02 at 10:35 +0800, Tang, Feng wrote:
>> Hi Bjorn,
>>
>> On Sat, 31 Jul 2010 04:58:48 +0800
>> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>>
>> > Hello Feng,
>> >
>> > Can you educate me about your commit 772be899bc, "86: Make EFI RTC
>> > function depend on 32bit again"?
>> >
>> > It adds "#ifdef CONFIG_X86_32" to avoid using efi_get_time() and
>> > efi_set_rtc_mmss(), but there's no explanation of *why* those services
>> > only work on 32-bit.
>> >
>> > Is this an EFI spec limitation? Do the other EFI runtime services
>> > work on 64-bit, since you didn't touch them? Or do we just not use
>> > any of the others?
>> >
>>
>> Commit 772be899bc, "86: Make EFI RTC function depend on 32bit again" is
>> a regression fix for 7bd867d "x86: Move get/set_wallclock to x86_platform_ops".
>> These 2 commits just abstract the rtc service for legacy x86 PC/EFI/Virtualiation
>> kernel, and has no functional change to existing code.
>>
>> I'm not familiar with EFI, but my understanding is current EFI code in
>> kernel only provides the get/set_time service for x86_32 platform.
>
> I think get/set_time service should have worked on x86_64 too. Just
> lacks proper debugging/testing for recent kernels.
Is there any reason we just don't rip those calls out?
If we don't need them and we lack proper debug/testing I don't see the point
of using the EFI calls and exposing ourselves to more potential BIOS breakage.
EFI runtime calls have the nasty fact that they don't work in general even
if EFI is present because you may have the wrong word size EFI running on
your machine. A 32bit EFI and a 64bit kernel or a 64bit EFI and a 32bit kernel.
Eric
next prev parent reply other threads:[~2010-08-03 21:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 20:58 EFI runtime-services on x86_64 Bjorn Helgaas
2010-08-02 2:35 ` Feng Tang
2010-08-02 2:42 ` Huang Ying
2010-08-03 21:45 ` Eric W. Biederman [this message]
2010-08-03 21:53 ` Matthew Garrett
2010-08-03 21:58 ` Eric W. Biederman
2010-08-03 22:15 ` Matthew Garrett
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=m14ofbgyki.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=bjorn.helgaas@hp.com \
--cc=feng.tang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=ying.huang@intel.com \
/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