LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Edgar Hucek <hostmaster@ed-soft.at>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>,
	akpm@osdl.org
Subject: Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
Date: Wed, 05 Jul 2006 11:38:00 +0200
Message-ID: <44AB8878.7010203@ed-soft.at> (raw)
In-Reply-To: <m11wt3983j.fsf@ebiederm.dsl.xmission.com>

I agre with you to make efi use the e820 map as a long term solution.
But at the moment the efi part is completley broken without my patch.
At least on Intel Macs. 
Without the patch also my Imacfb driver makes no sense, since it is 
for efi booted Intel Macs. 

cu

Edgar (gimli) Hucek

Eric W. Biederman schrieb:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>> Eric W. Biederman wrote:
>>
>>>> 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?
>>>
>> 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
> 


  parent reply index

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-26 21:19 Edgar Hucek
2006-06-26 21:33 ` Linus Torvalds
2006-06-27  6:15   ` Edgar Hucek
2006-06-27  6:20     ` Linus Torvalds
2006-06-28 22:37       ` H. Peter Anvin
2006-07-02 17:39         ` Eric W. Biederman
2006-07-02 17:42           ` H. Peter Anvin
2006-07-02 18:26             ` Eric W. Biederman
2006-07-02 18:46               ` Arjan van de Ven
2006-07-05  9:38               ` Edgar Hucek [this message]
2006-07-05 15:52                 ` Eric W. Biederman
2006-07-13 21:46                   ` Edgar Hucek
2006-07-13 22:15                     ` Linus Torvalds
2006-07-14  4:23                       ` Eric W. Biederman
2006-07-14  6:22                         ` H. Peter Anvin
2006-07-14  6:20                       ` Edgar Hucek
2006-07-14 16:09                         ` Linus Torvalds
2006-07-16  8:55                           ` [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1] Edgar Hucek
2006-07-25  4:29                             ` Andrew Morton
2006-07-25  5:17                               ` Eric W. Biederman
2006-07-25  5:32                               ` Linus Torvalds
2006-07-25  5:34                                 ` H. Peter Anvin
2006-07-25  5:44                                   ` Linus Torvalds
2006-07-25  6:26                                     ` H. Peter Anvin
2006-07-25  6:00                                 ` Linus Torvalds
2006-07-16  9:00                           ` [PATCH 1/1] Add force of use MMCONFIG " Edgar Hucek
2006-07-25  4:33                             ` Andrew Morton
2006-07-25  5:27                               ` Linus Torvalds
2006-07-26 15:05                                 ` Andi Kleen
2006-06-26 22:22 [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4] Thomas Meyer
2006-07-14 13:57 Chuck Ebbert
2006-07-14 14:45 ` Edgar Hucek
2006-07-14 19:28 ` Edgar Hucek
2006-07-16 12:09 Thomas Meyer

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=44AB8878.7010203@ed-soft.at \
    --to=hostmaster@ed-soft.at \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git