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, 5 Dec 2019 15:12:03 -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: <84c4ee600c0dd235a0fcc257115807af7207b5f6.camel@wdc.com>
Message-ID: <alpine.DEB.2.21.9999.1912051435130.239155@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>  <alpine.DEB.2.21.9999.1912041644170.206929@viisi.sifive.com> <84c4ee600c0dd235a0fcc257115807af7207b5f6.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 Thu, 5 Dec 2019, Alistair Francis wrote:

> On Wed, 2019-12-04 at 18:54 -0800, Paul Walmsley wrote:
> > On Wed, 4 Dec 2019, Alistair Francis wrote:
> > 
> > > 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.
> 
> That might be true for the traditional "desktop" distros, but embedded
> distros (the main target for RISC-V at the moment) don't generally do
> this.

Maybe in this discussion we can agree to use the common distinction 
between distributions and distribution build frameworks, where users of 
the latter need to be more technically sophisticated - as opposed to 
downloading a disk image.

> > > 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.
> 
> Yes they do. As I said, we start with the defconfig and then apply
> config changes on top. Every diversion is a maintainence burden so
> where possible we don't make any changed. All of the QEMU machines
> currently don't have config changes (and hopefully never will) as it's
> a pain to maintain.

I'm open to your concerns here.  Can you help me understand why adding a 
few lines to the kernel configuration fragments to disable the debug 
options creates maintenance pain?  Isn't it just a matter of adding a few 
lines to disable the debug options, and -- since you clearly don't want 
them enabled for any platform -- just leaving them in there?

> > > > 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 
> 
> That is just not true. 

After getting your response, I reviewed the OE-core tree that I have here, 
which is based on following the OE-core "getting started" instructions. 
The result is a tree with no RISC-V machine support.  Looking again at 
those instructions, I see that they check out the last release, rather 
than the current top of the tree; and the current top of tree does have a 
QEMU RISC-V machine.  So this statement of yours is correct, and I was in 
error about the current top-of-tree OE-core support.

> You talk later about misinformation but this is a blatent lie.

This isn't acceptable.  We've met each other in person, and I've 
considered you an enjoyable and trustworthy person to discuss technical 
issues with.  This is the first time that you've ever publicly accused me 
of misrepresenting an issue with intent to deceive.  There's a big 
difference between stating that someone is quoting misinformation and 
accusing someone of bad intentions.  I expect an apology from you.

> > > 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
> 
> What misinformation?

You've already acknowledged in your response that the major Linux 
distributions don't use defconfigs.  So it's clear that your statement is 
false, and rather than admitting that you're wrong, you're doubling down.

> > exaggerating the difficulty for downstream software environments to 
> > back this change out if they wish.
> 
> If you think it is that easy can you please submit the patches?

For my part, I'd be happy if the current RISC-V OE and Buildroot users who 
don't change the kernel configs run with the defconfig debug options 
enabled right now.   So, I don't plan to send patches for them.

> I understand it's easy to make decisions that simplfy your flow, but
> this has real negative consequences in terms of performance for users
> or complexity for maintainers. It would be nice if you take other users
> /developers into account before merging changes.

As stated earlier, I'm open to reconsidering if it indeed is onerous, and 
not just a matter of patching a few lines of kernel configuration 
fragments in OE and Buildroot once.


- Paul