[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOJsxLFWMi8DoFp+ufri7XoFO27v+2=0oksh8+NhM6P-OdkOwg@mail.gmail.com>
Date: Thu, 14 Nov 2013 20:44:04 +0200
From: Pekka Enberg <penberg@...nel.org>
To: Jerry Hoemann <jerry.hoemann@...com>
Cc: "H. Peter Anvin" <hpa@...or.com>, Rob Landley <rob@...dley.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
x86 maintainers <x86@...nel.org>,
Matt Fleming <matt.fleming@...el.com>,
Yinghai Lu <yinghai@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"list@...ederm.org:DOCUMENTATION <linux-doc@...r.kernel.org>,
list@...ederm.org:MEMORY MANAGEMENT <linux-mm@...ck.org>,"
<linux-doc@...r.kernel.org>, linux-efi@...r.kernel.org,
Vivek Goyal <vgoyal@...hat.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] Early use of boot service memory
On Thu, Nov 14, 2013 at 8:04 PM, <jerry.hoemann@...com> wrote:
> Making this issue a quirk will be a lot more practical. Its a small, focused
> change whose implications are limited and more easily understood.
There's nothing practical with requiring users to pass a kernel option
to make kdump work. It's a workaround, sure, but it's not a proper
fix.
And once you add whitelisting to make it practical, implications are
no longer limited nor easily understood nor actually testable unless
you happen to have access every single firmware out there.
Yes, we have plenty of quirks in the x86 boot code but that doesn't
mean it's a good idea to add more of the unless we absolutely must.
Pekka
--
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