Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
- Date: Sun, 02 Jul 2006 12:26:08 -0600
"H. Peter Anvin" <hpa@xxxxxxxxx> writes:
Eric W. Biederman wrote:
itYou 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
atmakes more sense for the kernel to be as self-sufficient as is possible, or
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?
If nothing else, they should be isolated, and in the early kernel build a
datastructure like the e820 data structure, so the downstream kernel doesn't
deal with it.
I have no idea what the above does; it sounds to me like something that should
be possible to do differently, though.
Quite.
The part that is an obvious hack is that it shows up in init/main.c
for no apparent reason. Instead of being in architecture specific code
since it only applies to one architecture. ia64 which also uses efi
doesn't need to patch init/main.c
Basically this was just an example to add to the e820 map problem of what
a problem this code really is.
Thinking about the e820 problem. That is in the function:
e820_all_mapped(unsigned long s, unsigned long e, unsigned type)
Which is a test. I believe this is the sanity check to ensure the
pci express memory mapped configuration area is accessible.
In which case disabling the test is totally wrong,
and I agree with Linus that we need to convert the structure.
We need to know what the BIOS's idea of the memory map is and to be
able to query it.
Although I am surprised we could not just make that query by looking
at the resources. Possibly we are too early in boot.
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/
- Follow-Ups:
- Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- From: Edgar Hucek
- Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- From: Arjan van de Ven
- Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- References:
- Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- From: Eric W. Biederman
- Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- From: H. Peter Anvin
- Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- Prev by Date: [PATCH] consistently use MAX_ERRNO in __syscall_return
- Next by Date: Re: 2.6.17: Yet another .config that won't build
- Previous by thread: Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- Next by thread: Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
- Index(es):
Relevant Pages
|
