Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c2f91d00-96d2-c1f4-c858-5619515a30ed@huawei.com>
Date:   Mon, 25 Jul 2022 18:39:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: [PATCH 0/2] arm64 defconfig: Get faddr2line working
To:     Arnd Bergmann <arnd@arndb.de>
CC:     Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Olof Johansson <olof@lixom.net>, SoC Team <soc@kernel.org>,
        <jpoimboe@kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
References: <1658681004-132191-1-git-send-email-john.garry@huawei.com>
 <CAK8P3a0umWWic6LAzxXJ7BACYVE--m-wbynh7Z8F+pGoUBxGTA@mail.gmail.com>
 <25237c44-ebc4-fc9a-7c6f-3e990f968038@huawei.com>
 <CAK8P3a2+0EwSJ=fRBL2JCGypJRL-qE4rEiXYnJbqhZ=weethdQ@mail.gmail.com>
 <4d5c9bfc-dc10-7019-cad4-751e21f02a18@huawei.com>
 <CAK8P3a3QNjOSodb-ND=nZ=ThC9xZhEyUOaUsWCDF70s9g80r-w@mail.gmail.com>
From:   John Garry <john.garry@huawei.com>
In-Reply-To: <CAK8P3a3QNjOSodb-ND=nZ=ThC9xZhEyUOaUsWCDF70s9g80r-w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 25/07/2022 15:22, Arnd Bergmann wrote:
>> INTERCONNECT has no dependencies, so "select" - like for MAILBOX -
>> should be fine, I suppose
> There are a couple of trade-offs between the two approaches.
> The main advantage of 'select' is that you can enable drivers more
> easily and all the required subsystems are there automatically.
> The advantage of 'depends on' is that it becomes easier to disable
> entire subsystems that one may not need.
> 
> Which of those two is more important is of course a matter of perspective,
> I like to be able to turn things off more easily because that makes it
> possible to test the corner cases with randconfig more easily, and it
> helps produce size-reduced kernels for embedded systems.
> 
> Another aspect is that we overall have more 'depends on' than 'select',
> and sticking with the more common way avoids circular dependencies,
> both within an area of the kernel and overall.
> 
> The rule that I tend to follow with 'select' is to only use it on symbols
> that you don't even want to show to users. If a feature is part of
> a library (think zlib), then each user just needs to select the symbol
> but you never actually have to decide whether to show it or not.

ok, seems reasonable. Personally I dislike 'select' for all the common 
reasons.

> 
>>>> And would each config item deletion merit a separate patch?
>>> You send a combined patch for the obvious ones (secccomp
>>> and mailbox AFAICT) or send them separately. For the other ones I think
>>> we should try fixing the Kconfig files first, otherwise we just end up
>>> putting them back afterwards.
>> ok, fine. I'll deal with the obvious changes first plus
>> CONFIG_DEBUG_INFO and then the non-obvious, non-trivial ones. I'll base
>> on your arm/defconfig branch (for defconfig changes).
> The CONFIG_DEBUG_INFO one should be fixed by my series from
> last week already, do you still see another issue with that?

Ah, I thought that you re-enabled CONFIG_DEBUG_INFO for only the arm32 
configs but see that you also re-enabled for arm64 defconfig as well.

> I actually
> have another patch to fix up all the non-Arm defconfigs for this one as
> well, but haven't sent that one yet.

Thanks,
John