Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933674AbbELRjg (ORCPT ); Tue, 12 May 2015 13:39:36 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:35717 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932847AbbELRjf (ORCPT ); Tue, 12 May 2015 13:39:35 -0400 MIME-Version: 1.0 In-Reply-To: <20150512092821.GA10900@gmail.com> References: <1428518512-13460-1-git-send-email-mjg59@coreos.com> <1428611100-23337-1-git-send-email-mjg59@srcf.ucam.org> <20150512092821.GA10900@gmail.com> Date: Tue, 12 May 2015 10:39:33 -0700 Message-ID: Subject: Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init From: Matthew Garrett To: Ingo Molnar Cc: Matthew Garrett , x86@kernel.org, hpa@zytor.com, mingo@redhat.com, tglx@linutronix.de, Linux Kernel Mailing List , Matthew Garrett Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1648 Lines: 42 On Tue, May 12, 2015 at 2:28 AM, Ingo Molnar wrote: > > * Matthew Garrett wrote: > >> Any feedback on this? > > So I worry about: > > - the fragmented nature of it: lots of non-obvious pieces of code > will now be scattered all around arch/x86/. We've got four different entry points and they all work under very different constraints - I can't see any real way to share this code. We could move all the command line handling code into a single file and #include it with different ifdefs, but I'm not sure that that's less confusing? > - the crazy #ifdefs scattered around The #ifdefs could be abstracted behind a couple of simple helper functions? > - the various pieces of data scattered around We're trying to use the same data in what are pretty much four logically distinct codebases. I'm not sure that there's any way around that other than linker magic, and that seems like it'd make things even more non-obvious. > ... so while I don't mind the feature in principle, but it should be > centralized much better IMHO, made Kconfig invariant at least in its > fragmented callbacks, with only the very strictly boot method specific > details spelled out explicitly. > > I have not thought much about how to achieve that :-/ I'm happy to reimplement this, but outside losing the #ifdefs I'm struggling to see any real way of improving it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/