Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Eric W. Biederman]

"H. Peter Anvin" <hpa@xxxxxxxxx> writes:

> Linus Torvalds wrote:
>> On Tue, 27 Jun 2006, Edgar Hucek wrote:
>>> So what is your suggestion to get the working funktionality
>>> from kernel 2.6.16 back ? 2.6.17 have broken it.
>> I'd really suggest just filling in the e820 table from the EFI information
>> early at boot.
>> (Even better would be for the EFI bootloader on x86 to just fill things in
>> _as_if_ it was filling in e820 data, but that's outside of the kernel, so if
>> you want the _kernel_ to be able to handle native EFI data, do it by just
>> translating it once into e820 mode, and you're done).
>> The translation from EFI to e820 format should be very straightforward
>> indeed. I think it's pretty much the same thing with different naming.
>>
>
> You probably don't want to put it in the bootloader.  The kernel is easier to
> upgrade than the bootloader, which is easier to upgrade than the firmware, so it
> makes more sense for the kernel to be as self-sufficient as is possible, or at
> least practical.

Regardless it would be nice if the efi implementation hacks were removed.

My favorite is this one in init/main.c 
#ifdef CONFIG_X86
	if (efi_enabled)
		efi_enter_virtual_mode();
#endif

Which pretty much guarantees efi won't be a distro supported feature
any time soon because it breaks kexec the ability of a kexec'd kernel
to boot and thus crash dump support. Or it does if you ever use efi
callbacks, and if you don't use efi callbacks there is no point in
calling that function.  Why are efi callbacks not always done in
physical mode?

Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/