From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754015Ab3KOGY3 (ORCPT ); Fri, 15 Nov 2013 01:24:29 -0500 Received: from mail-ee0-f54.google.com ([74.125.83.54]:47087 "EHLO mail-ee0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750920Ab3KOGYV (ORCPT ); Fri, 15 Nov 2013 01:24:21 -0500 Date: Fri, 15 Nov 2013 07:24:17 +0100 From: Ingo Molnar To: jerry.hoemann@hp.com Cc: Pekka Enberg , "H. Peter Anvin" , Rob Landley , Thomas Gleixner , Ingo Molnar , x86 maintainers , Matt Fleming , Yinghai Lu , Andrew Morton , "list@ebiederm.org:DOCUMENTATION , list@ebiederm.org:MEMORY MANAGEMENT ," , linux-efi@vger.kernel.org, Vivek Goyal , LKML Subject: Re: [PATCH 0/3] Early use of boot service memory Message-ID: <20131115062417.GB9237@gmail.com> References: <1384222558-38527-1-git-send-email-jerry.hoemann@hp.com> <20131113224503.GB25344@anatevka.fc.hp.com> <52840206.5020006@zytor.com> <20131113235708.GC25344@anatevka.fc.hp.com> <20131114180455.GA32212@anatevka.fc.hp.com> <20131115005049.GJ5116@anatevka.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131115005049.GJ5116@anatevka.fc.hp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * jerry.hoemann@hp.com wrote: > On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote: > > On Thu, Nov 14, 2013 at 8:04 PM, 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. > > One already has to specify command line arguments to enable kdump. > See "crashkernel=" in Documentation/kernel-parameters.txt. That option is already a usability barrier. Adding yet another usability barrier improves things how? > As i said in an earlier mail we are working w/ distros. [...] The point being? > [...] distros can and do specify lots of interesting command line > arguments for their systems. Distros have tools for configuring > kdump. User must already use these tools or manually edit multiple > config files, to get kdump to work. I would work with distros to > help integrate this change into their tools. Here you describe a method that has already successfully cut the kdump user base to a fraction of its potential size. Why should we assist to that effort of engineered obscurity? > As i said in earlier mail, i am willing to change implementation to > some type of black/white listing. Is it possible to fix it the way hpa suggested? Thanks, Ingo