mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Huang, Ying" <ying.huang@intel.com>
Cc: ak@suse.de, akpm@linux-foundation.org,
	Yinghai Lu <yhlu.kernel@gmail.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Chandramouli Narayanan <mouli@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] x86_64 EFI support -v3
Date: Mon, 30 Jul 2007 22:16:31 -0600	[thread overview]
Message-ID: <m1bqdtus0w.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1185851569.23149.25.camel@caritas-dev.intel.com> (Ying Huang's message of "Tue, 31 Jul 2007 11:12:49 +0800")

"Huang, Ying" <ying.huang@intel.com> writes:

> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> Interface) support to x86_64 architecture. The patches have been
> tested against 2.6.23-rc1 kernel on Intel platforms with EFI1.10 and
> UEFI2.0 firmware.
>
> UEFI specification can be found here: http://www.uefi.org

Is it still the case you must sign a license you won't implement
it if you read the specification?

> For booting the UEFI x86_64 enabled kernel, the machine with EFI/UEFI
> firmware and the support of bootloader is required. Detailed usage
> guide can be found in Documentation/x86_64/uefi.txt, which is added in
> the patch: efi-doc.patch.
>
> Issues _not_ addressed (per feedback from Eric Biederman)

Thank you for acknowledging them.

I would really prefer to see something start simple and obviously
correct and grow (typical unix/linux development) rather then
attempt to use all of the cool efi features at once.

> - Virtual mode support is still retained in this patch. There is at
>   least one EFI call is fast path: efi_set_rtc_mmss, which must
>   complete as soon as possible.

Bogus.  You are setting the wall clock time in the granularity
of a second.  Yes we can achieve high accuracy by setting things
as soon after the change as we can.  I don't see a couple of
extra micro second being a bit deal here.  If a couple of
extra micro seconds are a big deal we shouldn't be going through
efi to perform this logic in the first place.  This is x86 
and we know the hardware programming interface.

Why in the world are we going through efi for real time clock
operations anyway.  That seems completely silly.

> - The variable efi_enabled is used throughout across architecutres if
>  CONFIG_EFI option is enabled. The i386 code also uses this variable.
>  This is something that can be revisited with code consolidation
>  across architectures.

Fix it first. arch/i386/ efi support is horrible, and show what happens
when things are not done properly the first time.  Later doesn't happen.
With the partvirt logic we have a lot of operations properly split out
already.  Figure out how to use them. 

Ok. Looking what more I can tear into.

Eric

  reply	other threads:[~2007-07-31  4:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31  3:12 Huang, Ying
2007-07-31  4:16 ` Eric W. Biederman [this message]
2007-07-31  8:55   ` Huang, Ying
2007-08-01 17:21     ` Eric W. Biederman
2007-07-31  4:47 ` Eric W. Biederman
2007-08-06  5:40   ` Huang, Ying
2007-08-08 16:45     ` Eric W. Biederman
2007-08-08 20:41       ` Andi Kleen

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=m1bqdtus0w.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mouli@linux.intel.com \
    --cc=randy.dunlap@oracle.com \
    --cc=yhlu.kernel@gmail.com \
    --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

Powered by JetHome