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:   Wed, 4 Dec 2019 18:54:56 -0800 (PST)
From:   Paul Walmsley <paul.walmsley@sifive.com>
To:     Alistair Francis <Alistair.Francis@wdc.com>
cc:     "anup@brainfault.org" <anup@brainfault.org>,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        Atish Patra <Atish.Patra@wdc.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "hch@lst.de" <hch@lst.de>
Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1
In-Reply-To: <81530734312456aab8b9625d7e9bb071c43db1c5.camel@wdc.com>
Message-ID: <alpine.DEB.2.21.9999.1912041644170.206929@viisi.sifive.com>
References: <alpine.DEB.2.21.9999.1912040050430.56420@viisi.sifive.com>  <CAAhSdy2id0FoLBxWwN7WHEk5Am770BizkK=sZO0-G54MtYa6DQ@mail.gmail.com>  <9044bad02aa6553cdb2523294500b50fccf3fd2a.camel@wdc.com>  <alpine.DEB.2.21.9999.1912041128400.186402@viisi.sifive.com>
 <81530734312456aab8b9625d7e9bb071c43db1c5.camel@wdc.com>
User-Agent: Alpine 2.21.9999 (DEB 301 2018-08-15)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 4 Dec 2019, Alistair Francis wrote:

> That is just not what happens though.
> 
> It is too much to expect every distro to maintain a defconfig for RISC- 
> V. 

The major Linux distributions maintain their own kernel configuration 
files, completely ignoring kernel defconfigs.  This has been so for a long 
time.

> Which is why we currently use the defconfig as a base and apply extra 
> features that distro want on top.

As you know, since you've worked on some of the distribution builder 
frameworks (not distributions) like OE and Buildroot, those build systems 
have sophisticated kernel configuration patching and override systems that 
can disable the debug options if the maintainers think it's a good idea to 
do that.

You've contributed to both Buildroot and OE meta-riscv RISC-V kernel 
configuration fragments yourself, so this shouldn't be a problem for you 
if you disagree with our choices here.  For example, here's an example of 
how to patch defconfig directives out in Buildroot:

  https://git.buildroot.net/buildroot/tree/board/qemu/csky/linux-ck807.config.fragment#n3

I'm assuming you don't need an example for meta-riscv, since you've 
already contributed RISC-V-related kernel configuration fragments to that 
repository.

> Expecting every distro to have a kernel developers level of knowledge
> about configuring Kconfigs is just unrealistic.

I think it's false that only kernel developers know how to disable debug 
options in Kconfig files.  As far as the underlying premise that one 
shouldn't expect distribution maintainers to know how to change Kconfig 
options, we'll just have to agree to disagree.

> > distros and benchmarkers will create their own Kconfigs for their
> > needs.
> 
> Like I said, that isn't true. After this patch is applied (and it makes 
> it to a release) all OE users will now have a slower RISC-V kernel.

OE doesn't have any RISC-V support upstream, so pure OE users won't notice 
any change at all.  Assuming you're talking about meta-riscv users: as 
noted above, it's simple to automatically remove Kconfig entries you 
disagree with, or add ones you want.

> Now image some company wants to investigate using a RISC-V chip for
> their embedded project. They use OE/buildroot to build a quick test
> setup and boot Linux. It now runs significantly slower then some other
> architecture and they don't choose RISC-V.

The best option for naive users who are seeking maximum performance is to 
use a vendor BSP.  This goes beyond settings in a kernel config file: it 
extends to compiler and linker optimization flags, LTO, accelerator 
firmware and libraries, non-upstreamed performance-related patches, 
vendor support, etc.

> Slowing down all users to help kernel developers debug seems like the
> wrong direction. Kernel developers should know enough to be able to
> turn on the required configs, why does this need to be the default?

It's clear you strongly disagree with the decision to do this.  It's 
certainly your right to do so.  But it's not good to spread misinformation 
about how changing the defconfigs "slow[s] down all users," or 
exaggerating the difficulty for downstream software environments to back 
this change out if they wish.


- Paul