LKML Archive on
 help / color / Atom feed
From: Paul Walmsley <>
To: Alistair Francis <>
Cc: "" <>,
	"" <>,
	Atish Patra <>,
	"" <>,
	"" <>
Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1
Date: Wed, 4 Dec 2019 18:54:56 -0800 (PST)
Message-ID: <> (raw)
In-Reply-To: <>

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 

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

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 

> 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

  parent reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04  8:52 Paul Walmsley
2019-12-04 12:52 ` Anup Patel
2019-12-04 18:38   ` Alistair Francis
2019-12-04 19:38     ` Paul Walmsley
2019-12-04 19:50       ` Alistair Francis
2019-12-04 23:46         ` Anup Patel
2019-12-05  2:54         ` Paul Walmsley [this message]
2019-12-05  3:58           ` Alistair Francis
2019-12-05  5:35             ` David Abdurachmanov
2019-12-05 13:19               ` Anup Patel
2019-12-05 23:12             ` Paul Walmsley
2019-12-05 23:35               ` Alistair Francis
2019-12-05 23:46                 ` Alistair Francis
2019-12-06 21:12                   ` Carlos Eduardo de Paula
2019-12-06 21:15                     ` Anup Patel
2019-12-06 21:21                       ` Carlos Eduardo de Paula
2019-12-06 21:22                       ` Linus Torvalds
2019-12-04 19:25 ` pr-tracker-bot

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone