Message-ID: <20181101133249.g4ieomqb3wrawwvj@excalibur.cnev.de>
Date:   Thu, 1 Nov 2018 14:32:51 +0100
From:   Karsten Merker <merker@...ian.org>
To:     Olof Johansson <olof@...om.net>, Palmer Dabbelt <palmer@...ive.com>
Cc:     Albert Ou <aou@...s.berkeley.edu>, anup@...infault.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>, atish.patra@....com,
        davem@...set.davemloft.net, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] RISC-V: defconfig: Enable printk timestamps

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

Powered by blists - more mailing lists