From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933038AbcLGVIj (ORCPT ); Wed, 7 Dec 2016 16:08:39 -0500 Received: from mout.kundenserver.de ([217.72.192.73]:57011 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753554AbcLGVId (ORCPT ); Wed, 7 Dec 2016 16:08:33 -0500 From: Arnd Bergmann To: Bartlomiej Zolnierkiewicz Cc: Olof Johansson , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Russell King Subject: Re: [RFC PATCH 00/23] arm: defconfigs: use kconfig fragments Date: Wed, 07 Dec 2016 22:07:43 +0100 Message-ID: <8292218.3BDisRkZdU@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <4222703.VA8eKM008t@amdc3058> References: <1481027938-31831-1-git-send-email-b.zolnierkie@samsung.com> <4222703.VA8eKM008t@amdc3058> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:tu99BjitxAf30Wzp6hxYpctXIEhoEUwX4OBp/SuanSedC6kRR4s kdIjhkMBEbobG5VDBJVgfDOhcF9ZuK91j8s1EMzKHwE4kJ6ye9QCggpGgS0gxlq5RPMKRxx mstAP42yLr6qYVvAomlpPBepKiFcSoqrpHy746Qnt/oeVPvEYhOmEJeZ1o61uVdIpYEdMfU eA8byihKT1G1w/qOXjlog== X-UI-Out-Filterresults: notjunk:1;V01:K0:O59AAHR9I/0=:TSl9yufc3Xmi/YOLrx2u0Q iLeyLuISZFOAKAyKZPJHZDWGBnZDYO23KVMAJYTO6zVYCYEKQpyKfpm6dSmWBRmaSTmt3ieOV Y3yuuo5bj3M6iVdnGRNVCcB8GVPsKFw7V6/qcQjIJlltUZ8pRy7YXZ2mlqmc8OVKkJAPNdKMf ggZ8m6iM+Bk81/v0vIs75tjKILMDsCQqSpgoWkrgknH/mWKs1rDK9vRJCi5qLLe1TKg+DdrBs 4GKjdv9wl2y/NMMEiAjJj3siWOg7dGQu4m77Pyq5aug8rdwLYNyaYEPgaYN/RyjNfMOThMbEY j8WDxzr8oYFJ6Dp2oDGWf3H0FqKvA7V7/wEtBqWRqi1JW9yi4/mxoqIbaUCpb64A8wB9dDXTn xeiHfQX+z/j2KIZ6lWLQsJqKF71prrE3jaH0MXn5Ks0hca8ZmM1Itv6+AotCnTa7+VX7qeZg1 mLxoLYkdMrKwIdGBMVEiwDfwOzhpjjO7tS9usJQggQuG5twoVt9jMKcaGn+hCs8fRPrN8iPh6 29tlDo8Uhn57x48E9ElIyhjLJKJILjOtMZw40FPksZo+LRS13RwGwrVkwFiuE/TFVS6+78kKX eLeoiwhNa48MTIiF6RFQoBfUg1RyYHyBrGr8JtznEs6lq3RN4jcyQdgjU4OtAbI2X3UqScjdO L9a7potiv4G08xmXG6ze/lnl5ha0i0GyEA0dPmyvO/xXUoNbIYnw/hO1NUdfJplwQ8jdP8H7M UzjxOSDO3z0fGPLm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 7, 2016 12:41:29 PM CET Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, December 06, 2016 11:03:34 AM Olof Johansson wrote: > > On Tue, Dec 6, 2016 at 4:38 AM, Bartlomiej Zolnierkiewicz > > wrote: > > > Hi, > > > > > > This RFC patchset starts convertion of ARM defconfigs to use kconfig > > > fragments and dynamically generate defconfigs. The goals of this > > > work are to: > > > > You don't provide any motivation as to why this is better. As far as I > > Benefits are: > > - no code duplication (this initial patchset alone removes ~1700 lines > from defconfigs without any change in functionality) This may be interesting > - prevention of "multi" defconfigs (i.e. multi_v7_defconfig) going out > of sync with "SoC-family" ones (i.e. exynos_defconfig) - there will > be just one place to update when changing things I'm not convinced this is worthwhile: in a lot of cases, the soc-specific configs want to enable things built-in, while the more generic ones tend to use loadable modules. > - possibility to add support for more optimized defconfigs (i.e. board > specific ones) in the future without duplicating the code I'd prefer seeing fewer top-level options than more of them, so this doesn't really help. > - making it easier to define arch specific parts of defconfigs in > the future if we decide on doing it (i.e. we may want to enable > things like CONFIG_SYSVIPC for all defconfigs) The example you give is for something that should be decided in architecture-independent Kconfig language rather than per architecture, and that won't require fragments. > > am concerned it'll just be a mess. > > > > So: > > > > Nack. So much nack. I really don't want to see a proliferation of > > config fragments like this. > > > > I had a feeling it was a bad idea to pick up that one line config > > fragment before, since it opened the door for this kind of mess. > > Like I said in the cover-letter I'm not satisfied with the current > patches and they have much room for improvement. > > However I see that you don't like the idea itself... I do think that there is some room for more config fragments in mainline, but not most of the patches you have here. Some areas that I think would benefit from fragments are: - architecture level selection: v6/v6k/v7/v7ve/v8 could have a common defconfig file that starts out with all v6+ enabled, but then having fragments that disable the older architectures and platforms using them while turning on features that are only available on newer architectures - A "debug" fragment would be nice, to turn on common options that add a lot of useful runtime checks at the expense of performance or code size. - A "distro" fragment that turns on all loadable modules that are enabled by common distributions (e.g. two or more of debian/fedora/opensuse/gentoo), to let you build a drop-in replacement kernel for a shipping distro. This would also allow the distros to strip their own config files and just specify whatever differs from the others. Arnd