Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1

[Alistair Francis]

On Wed, 2019-12-04 at 11:38 -0800, Paul Walmsley wrote:
> Alistair, Anup,
> 
> On Wed, 4 Dec 2019, Alistair Francis wrote:
> 
> > On Wed, 2019-12-04 at 18:22 +0530, Anup Patel wrote:
> > 
> > > I had commented on your patch but my comments are still
> > > not addressed.
> > > 
> > > Various debug options enabled by this patch have performance
> > > impact. Instead of enabling these debug options in primary
> > > defconfigs, I suggest to have separate debug defconfigs with
> > > these options enabled.
> > 
> > +1
> > 
> > OE uses the defconfig (as I'm sure other distros do) and slowing
> > down
> > users seems like a bad idea.
> 
> While I respect your points of view, our defconfigs are oriented
> towards 
> kernel developers.  This is particularly important when right now the
> only 

That is just not what happens though.

It is too much to expect every distro to maintain a defconfig for RISC-
V. There are constantly new features that need to be enabled/disabled
in the configs and it isn't always clear to outsiders. Which is why we
currently use the defconfig as a base and apply extra features that
distro want on top.

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

> RISC-V hardware on the market are test chips.  Our expectation is
> that 

Treating RISC-V as a test architecture seems like a good way to make
sure that is all it ever is.

> 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.
This also applies to buildroot and probably other distos.

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.

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?

Alistair

> 
> Going forward, we'll probably add a few more validation and debug
> options, 
> as Palmer suggested during the patch discussion.
> 
> 
> - Paul