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

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 12/2/15 3:47 AM, Ian Campbell wrote:
> 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 I can do. I always expected that I would have a follow on series
(maybe even multiples) as I was able to tease out some of the
dependencies better. e.g. converting some of include/asm-ARCH/config.h

I would also happily add myself to MAINTAINERS for the Kconfig parts and
would ensure some kind of periodic sync up with Linux upstream. I'm not
looking at doing this conversion as a one and done but sticking around
for the long haul.

> 
> 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.
> 

Sure thing. I'll break that out. My plan was to convert them all. The
patch that does KEXEC was actually from the original RFC/v1 series where
it was just an example one and I never dropped it in later series
because it was useful for testing. I've got a follow on that converts
all the items in xen/Rules.mk that I have not posted to the list and I
can move the KEXEC into that series.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel