[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTikfbSsgGgNEQ3GVD=HOPn1Dz_xh+g@mail.gmail.com>
Date: Wed, 8 Jun 2011 14:06:21 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Yinghai Lu <yinghai@...nel.org>, Jim Bos <jim876@...all.nl>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Maarten Lankhorst <m.b.lankhorst@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: 2.6.39.1 immediately reboots/resets on EFI system
On Wed, Jun 8, 2011 at 1:42 PM, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
>
>> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
>
> That was my original approach, but if there's boot services code at the
> top of RAM it means that max_pfn is wrong and it's difficult to recover
> the memory.
WHO CARES if the memory is difficult to recover? Just let it be. EFI
is an abomination in the eyes of God, and we sure as hell shouldn't
bend over backwards over the stupidities in it. If it means that you
lose a meg of RAM when you use EFI, that's the least of our problems.
F*%#ing morons who thought that we wanted some kind of extensible
firmware interface. We want a *cut-down* firmware interface, not the
crazy thing that is EFI. A boot loader, not some kind of run-time
services crap. And we definitely don't want to make it any more
complex than we need to.
So just turn the EFI stuff into the memory map, and let the kernel do
as little as possible with it.
Linus
--
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