[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1185872127.23149.81.camel@caritas-dev.intel.com>
Date: Tue, 31 Jul 2007 16:55:27 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: ak@...e.de, akpm@...ux-foundation.org,
Yinghai Lu <yhlu.kernel@...il.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Chandramouli Narayanan <mouli@...ux.intel.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] x86_64 EFI support -v3
On Mon, 2007-07-30 at 22:16 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <ying.huang@...el.com> writes:
> > - 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.
What do you suggest to use instead of efi_enabled?
Current method is (efi_enabled based):
(1) Encapsulate EFI based implementation and legacy BIOS based
implementation into separate functions.
(2) Define a wrapper function for each interface in (1), efi_enabled is
used to choose implementation between EFI and legacy BIOS.
Another possible method is (function pointer based):
1. Encapsulate EFI based implementation and legacy BIOS based
implementation into separate functions.
2. Define a function pointer for each interface in (1), the function
pointer is set to legacy BIOS based implementation by default and
changed to EFI based implementation if appropriate.
Because there are only two possible choice, I think the function pointer
based method has no big advantages over the efi_enabled based method.
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists