Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 1 Nov 2018 14:32:51 +0100
From:   Karsten Merker <merker@debian.org>
To:     Olof Johansson <olof@lixom.net>, Palmer Dabbelt <palmer@sifive.com>
Cc:     Albert Ou <aou@eecs.berkeley.edu>, anup@brainfault.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Christoph Hellwig <hch@infradead.org>, atish.patra@wdc.com,
        davem@sunset.davemloft.net, linux-riscv@lists.infradead.org
Subject: Re: [PATCH] RISC-V: defconfig: Enable printk timestamps
Message-ID: <20181101133249.g4ieomqb3wrawwvj@excalibur.cnev.de>
References: <CAOesGMjXZNURZ4SdKjssYCcFv3=4MYLBpBpzvvb1rNM-fo=QHQ@mail.gmail.com>
 <mhng-111820e6-59c0-479a-a10f-f3729007ba70@palmer-si-x1c4>
 <CAOesGMj+wXcN_7yvakC=SvtYjO=TTqrs8YiVX1xT7-4p1pC_Mg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAOesGMj+wXcN_7yvakC=SvtYjO=TTqrs8YiVX1xT7-4p1pC_Mg@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 31, 2018 at 03:50:38PM -0700, Olof Johansson wrote:
> On Wed, Oct 31, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
[...]
> > When we first submitted out port upstream we had an empty defconfig, with the
> > theory being that we should just pick whatever the default in Kconfig is for
> > everything.  That's obviously the wrong thing to do because most of those
> > options are bogus.  At the time I didn't care enough to look because I just
> > wanted something to work, but now I find myself asking the question "what goes
> > in a defconfig?"  Is it:
> >
> > * What I, as the maintainer of arch/riscv, want?  That's essentially what it is
> >   now, as we have things like "CONFIG_R8169=y" in there because I happened to
> >   have one sitting around when we needed to plug in an Ethernet card to test
> >   out PCIe.
> > * What distributions expect?  There's a major element of this in there right
> >   now, as half this stuff was just selected because the Debian and Fedora guys
> >   suggested we do so because adding things to the RISC-V defconfig made it
> >   easier to put together their build scripts.  For example, we ended up with
> >   "CONFIG_EXPERT=y" because some setting necessary for the distros was hidden
> >   behind it -- that seems like an odd default.
> > * What users expect?  I'm not even sure who users are in this case, as from my
> >   understating most people use distro kernels and don't twiddle Kconfig
> >   options.
> > * What is necessary to work on RISC-V hardware?  This seems like the most
> >   reasonable use for an arch-specific defconfig, and subsumes things like
> >   "CONFIG_SIFIVE_PLIC=y" because without the PLIC driver nothing will work (but
> >   the PLIC driver shouldn't be enabled by default for all architectures, as
> >   it's useless everywhere else).
> >
> > Maybe I've opened up a big can of worms here...  It just seems silly to have
> > most of our current defconfig be RISC-V specific.
> 
> So, on 32-bit ARM we have heavy defconfig proliferation, and for arm64
> there was a push to only have one defconfig. I'm heavily in favor of
> the latter.

ACK.

> On ARM64, the options turned on, are more or less "what makes the
> kernel useful on systems". Anything that would be needed to boot to a
> rootfs tends to be =y, while some other things that might be optional
> and not used everywhere tends to go in as modules.

ACK.

> Beyond that, for the most part it is maintainer preference. I've
> normally turned on platforms and drivers I need for my boot farm on
> the multi*defconfig configs on 32-bit ARM, and the same has been going
> for 64-bit.
> 
> Distros will always want something different, for policy reasons or
> otherwise. Main purpose of mainline defconfigs is to make mainline
> kernels useful and bootable, so having more of a superset approach
> makes a lot of sense in my mind.

My personal approach to defconfigs is that they should try to
provide the minimum hardware-related options required to boot on
existing hardware or virtual machines for the corresponding
architecture, and the minimum non-hardware related kernel options
that are required to run a typical disto userland, but not more. 
This "minimum" can still be a rather long list, though.  On the
hardware side that can include lots of low-level drivers (e.g. 
various PMICs, USB and AHCI PHYs, the various platform-specifc
frontends for (more or less) generic drivers such as
OHCI/EHCI/XHCI/AHCI/DWMAC/MUSB, etc.).  On the software side,
that minimum includes common filesystems (ext*, FAT, NFS),
everything required for systemd as the latter is nowadays used to
boot a significant proportion of all Linux distros, and basic
network support, but not much more.  I don't think that a
defconfig should follow the "everything and the kitchen sink"
approach that the distros use for their kernel builds (and which
of course makes sense for their userbase) - the defconfig is
usually used for development builds and should be small to keep
build times down.  The typical "I want it all" distro user
usually doesn't build a defconfig but either uses a pre-built
distro kernel or re-builds with an existing distro kernel config,
so the primary criterion for a defconfig should IMHO be the needs
of developers.

The "CONFIG_EXPERT=y" mentioned above was IIRC necessary to
enable some feature required by systemd, so unfortunately it is
quasi-essential to run common distro userlands nowadays.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.