Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-12-01 at 14:04 -0600, Doug Goldstein wrote:
> On 11/30/15 11:19 AM, Ian Campbell wrote:
> > On Mon, 2015-11-30 at 11:00 -0600, Doug Goldstein wrote:
> > > Since there is a request to have KEXEC and the UARTs
> > > configurable by the user
> > 
> > Who asked for this?
> > 
> > I have quite a strong preference for not adding _any_ new[*] user
> > configurable options in this first pass, since I think those need to be
> > considered quite carefully whereas this first series should be largely
> > about the mechanics of introducing Kconfig files.
> > 
> > Ian.
> > 
> > [*] i.e. anything which is not already controllable by the current
> > .config
> > driven thing.
> > 
> 
> The ARM UARTs are the take away I had from conversations with Julien
> Grall

AIUI all Julien was asking for was that the same set of UARTs should be
enabled for arm32 or arm64 both before and after this series, not that they
should be user configurable (in this first pass at least).

TBH I think this series is getting bogged down in trying to do much all at
the same time, switching to Kconfig, making things newly user-selectable,
arranging for out of tree builds, some of which are either (potentially)
controversial or simply result in apparently unnecessary changes if the
reviewer is only expecting a subset of those changes (especially those only
expecting the first), leading to a few RTTs of back and forth with
reviewers.

I would encourage you to par this first series back to the simplest
possible "switch to Kconfig, retaining the exact same set of user facing
options as today" and avoid feature creep from people requesting new and
exciting things which the switch to Kconfig makes possible.

That way we can make progress on a mostly mechanical switch to Kconfig
without continuously getting side tracked on questions like whether this or
that should be user selectable or not.

All of the "feature-creep" (which I don't mean in the pejorative sense)
things can easily be done in a follow up series.

>  and reading past comments on the ML how people can change the ARM
> UARTs. Obviously if that's not desired I can drop that. I originally had
> them enabled as they are in config/arm{32,64}.mk and changed them to be
> user configurable later in the series.
> 
> As far as KEXEC goes, its a user configurable option now in Rules.mk.
> You can build "make kexec=n" and it will disable it. I chose that one as
> an original example in v1 of how a user configurable option would look
> in this scheme.

I don't have a problem with converting existing user-configurable options
into Kconfig in the first pass, that seems natural/justifiable enough to
me, and doing it in the final patch as you have done seems sensible.

Treading very carefully around the creeping-featuritis trap (:-)), it does
seem that if one of the user options from xen/Rules.mk is going to be
converted then they all ought to be. Perhaps that's a topic for a followup
series though.

Ian.