Messages in this thread | | | Date | Thu, 1 Nov 2018 14:32:51 +0100 | From | Karsten Merker <> | 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@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.
| |