From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 657A1C43334 for ; Mon, 25 Jul 2022 17:39:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236270AbiGYRju (ORCPT ); Mon, 25 Jul 2022 13:39:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229921AbiGYRjt (ORCPT ); Mon, 25 Jul 2022 13:39:49 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CAA61C912 for ; Mon, 25 Jul 2022 10:39:47 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ls6gs17tnz68737; Tue, 26 Jul 2022 01:37:45 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Mon, 25 Jul 2022 19:39:44 +0200 Received: from [10.126.173.156] (10.126.173.156) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 25 Jul 2022 18:39:44 +0100 Message-ID: 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 CC: Will Deacon , Catalin Marinas , Linux ARM , Olof Johansson , SoC Team , , "Linux Kernel Mailing List" References: <1658681004-132191-1-git-send-email-john.garry@huawei.com> <25237c44-ebc4-fc9a-7c6f-3e990f968038@huawei.com> <4d5c9bfc-dc10-7019-cad4-751e21f02a18@huawei.com> From: John Garry In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.126.173.156] X-ClientProxiedBy: lhreml723-chm.china.huawei.com (10.201.108.74) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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