Message-ID: <99bbf5710da82c8b52e59ad5fc4e44471573ecd3.camel@wdc.com>
Date:   Thu, 5 Dec 2019 23:35:12 +0000
From:   Alistair Francis <Alistair.Francis@....com>
To:     "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>
CC:     "anup@...infault.org" <anup@...infault.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Atish Patra <Atish.Patra@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hch@....de" <hch@....de>
Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1

On Thu, 2019-12-05 at 15:12 -0800, Paul Walmsley wrote:
> 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.

Why is there a distinction?

There are lots of disk images that you can just download which are
based on OE or buildroot. Lots of people use OE images and never
realise it.

In the same way that there are build enviroments based on the standard
"desktop" distros. In both cases these are distros.

> 
> > > > 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

For one, we have the same burden as you do.

You feel that it's too much of a burden to have a config fragment in
tree to enable debug. You clearly feel that having a
`extra_debug.config` fragment for you is too much of a burden, why is
it not a burden for distros?

> few 
> lines to disable the debug options, and -- since you clearly don't
> want 
> them enabled for any platform -- just leaving them in there?

Leave them in where?

No other architecture does this. Now we have to have a special config
fragment added just for RISC-V. Why is RISC-V so special that it needs
it's own fragment that other arches don't have?

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

The last release (Zeus) also has RISC-V 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.

I didn't say you had bad intentions. I was just pointing out that you
spent the time researching points that match your argument, but didn't
check to see what current RISC-V support is.

I don't see a difference between saying someone is spreading
misinformation and lying, but I am sorry if it upset 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?

Somehow it looks like you dropped this paragraph from my response, I'll
just add it back in:

******
Anup shared benchmarking results indicating that this change has a 12%
performance decrease for everyone who uses the defconfig without
removing this change.
******

> 
> You've already acknowledged in your response that the major Linux 
> distributions don't use defconfigs.  So it's clear that your 

What do you mean major?

AFAIK OE and buildroot are the only distros that have first class RISC-
V support. That seems pretty major to me.

> statement is 
> false, and rather than admitting that you're wrong, you're doubling
> down.

Doubling down on what? I never claimed all distros use defconfigs.

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

That is what will continue to happen. All users will be expected to
live with a 12% performance impact.

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

I don't understand, if patching a config is so easy why not just have a
fragment in the kernel tree and you can use that when you build a
kernel? This is what Daniel Thompson pointed out. That would avoid this
issue and have it easy for you to build a kernel with debug support.
How is that not the best solution?

AFIAK no other architecture has all these debug options enabled in the
defconfi, why is RISC-V so special?

Alistair

> 
> 
> - Paul

Powered by blists - more mailing lists