lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ