Linus,
The following changes since commit 5ba9aa56e6d3e8fddb954c2f818d1ce0525235bb:
Merge branch 'next/nommu' into for-next (2019-11-22 18:59:09 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv/for-v5.5-rc1-2
for you to fetch changes up to 1646220a6d4b27153ddb5ffb117aa1f4c39e3d1f:
Merge branch 'next/defconfig-add-debug' into for-next (2019-11-22 18:59:23 -0800)
----------------------------------------------------------------
Second set of RISC-V updates for v5.5-rc1
A few minor RISC-V updates for v5.5-rc1 that arrived late.
New features:
- Dump some kernel virtual memory map details to the console if
CONFIG_DEBUG_VM is enabled
Other improvements:
- Enable more debugging options in the primary defconfigs
Cleanups:
- Clean up Kconfig indentation
----------------------------------------------------------------
Krzysztof Kozlowski (1):
riscv: Fix Kconfig indentation
Paul Walmsley (4):
riscv: defconfigs: enable debugfs
riscv: defconfigs: enable more debugging options
Merge branch 'next/misc2' into for-next
Merge branch 'next/defconfig-add-debug' into for-next
Yash Shah (1):
RISC-V: Add address map dumper
arch/riscv/Kconfig.socs | 16 ++++++++--------
arch/riscv/configs/defconfig | 24 ++++++++++++++++++++++++
arch/riscv/configs/rv32_defconfig | 24 ++++++++++++++++++++++++
arch/riscv/mm/init.c | 32 ++++++++++++++++++++++++++++++++
4 files changed, 88 insertions(+), 8 deletions(-)
On Wed, Dec 4, 2019 at 2:22 PM Paul Walmsley <[email protected]> wrote:
>
> Linus,
>
> The following changes since commit 5ba9aa56e6d3e8fddb954c2f818d1ce0525235bb:
>
> Merge branch 'next/nommu' into for-next (2019-11-22 18:59:09 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv/for-v5.5-rc1-2
>
> for you to fetch changes up to 1646220a6d4b27153ddb5ffb117aa1f4c39e3d1f:
>
> Merge branch 'next/defconfig-add-debug' into for-next (2019-11-22 18:59:23 -0800)
>
> ----------------------------------------------------------------
> Second set of RISC-V updates for v5.5-rc1
>
> A few minor RISC-V updates for v5.5-rc1 that arrived late.
>
> New features:
>
> - Dump some kernel virtual memory map details to the console if
> CONFIG_DEBUG_VM is enabled
>
> Other improvements:
>
> - Enable more debugging options in the primary defconfigs
>
> Cleanups:
>
> - Clean up Kconfig indentation
>
> ----------------------------------------------------------------
> Krzysztof Kozlowski (1):
> riscv: Fix Kconfig indentation
>
> Paul Walmsley (4):
> riscv: defconfigs: enable debugfs
> riscv: defconfigs: enable more debugging options
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.
Please address my comments and send this patch in
separate PR.
Regards,
Anup
> Merge branch 'next/misc2' into for-next
> Merge branch 'next/defconfig-add-debug' into for-next
>
> Yash Shah (1):
> RISC-V: Add address map dumper
>
> arch/riscv/Kconfig.socs | 16 ++++++++--------
> arch/riscv/configs/defconfig | 24 ++++++++++++++++++++++++
> arch/riscv/configs/rv32_defconfig | 24 ++++++++++++++++++++++++
> arch/riscv/mm/init.c | 32 ++++++++++++++++++++++++++++++++
> 4 files changed, 88 insertions(+), 8 deletions(-)
On Wed, 2019-12-04 at 18:22 +0530, Anup Patel wrote:
> On Wed, Dec 4, 2019 at 2:22 PM Paul Walmsley <
> [email protected]> wrote:
> > Linus,
> >
> > The following changes since commit
> > 5ba9aa56e6d3e8fddb954c2f818d1ce0525235bb:
> >
> > Merge branch 'next/nommu' into for-next (2019-11-22 18:59:09
> > -0800)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> > tags/riscv/for-v5.5-rc1-2
> >
> > for you to fetch changes up to
> > 1646220a6d4b27153ddb5ffb117aa1f4c39e3d1f:
> >
> > Merge branch 'next/defconfig-add-debug' into for-next (2019-11-22
> > 18:59:23 -0800)
> >
> > ----------------------------------------------------------------
> > Second set of RISC-V updates for v5.5-rc1
> >
> > A few minor RISC-V updates for v5.5-rc1 that arrived late.
> >
> > New features:
> >
> > - Dump some kernel virtual memory map details to the console if
> > CONFIG_DEBUG_VM is enabled
> >
> > Other improvements:
> >
> > - Enable more debugging options in the primary defconfigs
> >
> > Cleanups:
> >
> > - Clean up Kconfig indentation
> >
> > ----------------------------------------------------------------
> > Krzysztof Kozlowski (1):
> > riscv: Fix Kconfig indentation
> >
> > Paul Walmsley (4):
> > riscv: defconfigs: enable debugfs
> > riscv: defconfigs: enable more debugging options
>
> 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.
Alistair
>
> Please address my comments and send this patch in
> separate PR.
>
> Regards,
> Anup
>
> > Merge branch 'next/misc2' into for-next
> > Merge branch 'next/defconfig-add-debug' into for-next
> >
> > Yash Shah (1):
> > RISC-V: Add address map dumper
> >
> > arch/riscv/Kconfig.socs | 16 ++++++++--------
> > arch/riscv/configs/defconfig | 24 ++++++++++++++++++++++++
> > arch/riscv/configs/rv32_defconfig | 24 ++++++++++++++++++++++++
> > arch/riscv/mm/init.c | 32
> > ++++++++++++++++++++++++++++++++
> > 4 files changed, 88 insertions(+), 8 deletions(-)
The pull request you sent on Wed, 4 Dec 2019 00:52:08 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv/for-v5.5-rc1-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6cdc7f2efc25a6dbddf7c57bb2eee5d6c033d678
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
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
RISC-V hardware on the market are test chips. Our expectation is that
distros and benchmarkers will create their own Kconfigs for their needs.
Going forward, we'll probably add a few more validation and debug options,
as Palmer suggested during the patch discussion.
- Paul
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
On Thu, Dec 5, 2019 at 1:20 AM Alistair Francis
<[email protected]> wrote:
>
> 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?
I quickly tried hackbench on SiFive Unleashed board with latest Linus
tree master branch (having your patch) and I am seeing 12% slowdown.
I am sure if I try more heavier benchmarks (such as stress-ng) then
the slowdown will be even more.
Here are the detailed numbers:
Command: ./hackbench 32
Number of Tasks: 32*40 (== 1280)
Average Time (without debug options): 3.10525
Average Time (with debug options): 3.471 (11.78% slower)
Command: ./hackbench 64
Number of Tasks: 64*40 (== 2560)
Average Time (without debug options): 6.3015
Average Time (with debug options): 7.05875 (12.017% slower)
Command: ./hackbench 128
Number of Tasks: 128*40 (== 5120)
Average Time (without debug options): 12.6275
Average Time (with debug options): 14.1455 (12.0214% slower)
It is this performance impact due to which other architectures (such as
x86 and ARM64) don't have these debug options enabled in their defconfigs.
I will send a patch to move these debug options to separate debug
defconfigs so that people have a way to build a debug kernel.
Regards,
Anup
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
On Wed, 2019-12-04 at 18:54 -0800, Paul Walmsley wrote:
> 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.
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.
>
> > 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.
>
> 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.
As I stated, this is possible. It's just a pain to maintain and for the
QEMU machines will probably not happen.
We are trying to remove RISC-V specific changes, not add more.
>
> > 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.
Do you really expect every disto to follow all of the kernel changes
and generate their own config based on what happened in the kernel tree
since the last release? We don't all just spend our days adjusting to
the Linux kernel.
This is espicially true for RISC-V as it's new and constantly changing.
>
> > > 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. You talk later about misinformation but this is
a blatent lie.
> 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.
What? How many people actually do this for embedded systems.
I agree that if you really want to maximise it as much as you can you
will go to this effort, but I don't think most people do. I think we
all know that lots of times embedded Linux is just hacked until it
works and then shipped. In this case defaults are very important.
>
> > 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?
Anup shared benchmarking results indicating that this change has a 12%
performance decrease for everyone who uses the defconfig without
removing this change.
That is everyone who doesn't decide to remove config options from the
default config supplied by the people who wrote the code are now stuck
with a large performance hit. Passing the buck and saying that people
should be changing the defconfig cannot be the right solution here.
> 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?
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.
Alistair
>
>
> - Paul
On Thu, Dec 5, 2019 at 5:58 AM Alistair Francis
<[email protected]> wrote:
>
> On Wed, 2019-12-04 at 18:54 -0800, Paul Walmsley wrote:
> > 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.
>
> 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.
I can confirm that Fedora/CentOS/RHEL do not depend on default
config in kernel. Same seems to apply to Ubuntu, Arch and probably
others. We maintain our own configs.
>
> >
> > > 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.
>
> >
> > 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.
>
> As I stated, this is possible. It's just a pain to maintain and for the
> QEMU machines will probably not happen.
>
> We are trying to remove RISC-V specific changes, not add more.
>
> >
> > > 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.
>
> Do you really expect every disto to follow all of the kernel changes
> and generate their own config based on what happened in the kernel tree
> since the last release? We don't all just spend our days adjusting to
> the Linux kernel.
I cannot talk for all distros (there are too many), but major desktop
distributions do that. For the 1st few RCs of a new kernel version I
will be adjusting Fedora/RISCV configuration based on whatever
changes land.
Of course looking at default defconfig is part of that process.
>
> This is espicially true for RISC-V as it's new and constantly changing.
>
> >
> > > > 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. You talk later about misinformation but this is
> a blatent lie.
>
> > 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.
>
> What? How many people actually do this for embedded systems.
>
> I agree that if you really want to maximise it as much as you can you
> will go to this effort, but I don't think most people do. I think we
> all know that lots of times embedded Linux is just hacked until it
> works and then shipped. In this case defaults are very important.
>
> >
> > > 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?
>
> Anup shared benchmarking results indicating that this change has a 12%
> performance decrease for everyone who uses the defconfig without
> removing this change.
>
> That is everyone who doesn't decide to remove config options from the
> default config supplied by the people who wrote the code are now stuck
> with a large performance hit. Passing the buck and saying that people
> should be changing the defconfig cannot be the right solution here.
>
> > 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?
>
> 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.
I would prefer to have a separate config for debug (that's what we do in
Fedora). Why not use config fragment here (e.g. call it debug.config like
in powerpc)?
See:
https://github.com/torvalds/linux/commit/c1bc6f93f95970f917caaac544a374862e84df52
https://elinux.org/images/3/39/Managing-Linux-Kernel-Configurations-with-Config-Fragments-Darren-Hart-VMware.pdf
david
>
> Alistair
>
> >
> >
> > - Paul
On Thu, Dec 5, 2019 at 11:06 AM David Abdurachmanov
<[email protected]> wrote:
>
> On Thu, Dec 5, 2019 at 5:58 AM Alistair Francis
> <[email protected]> wrote:
> >
> > On Wed, 2019-12-04 at 18:54 -0800, Paul Walmsley wrote:
> > > 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.
> >
> > 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.
>
> I can confirm that Fedora/CentOS/RHEL do not depend on default
> config in kernel. Same seems to apply to Ubuntu, Arch and probably
> others. We maintain our own configs.
Thanks for the confirmation. Unfortunately, this does not apply to
Yocto and Buildroot (and there could be others too).
>
> >
> > >
> > > > 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.
> >
> > >
> > > 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.
> >
> > As I stated, this is possible. It's just a pain to maintain and for the
> > QEMU machines will probably not happen.
> >
> > We are trying to remove RISC-V specific changes, not add more.
> >
> > >
> > > > 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.
> >
> > Do you really expect every disto to follow all of the kernel changes
> > and generate their own config based on what happened in the kernel tree
> > since the last release? We don't all just spend our days adjusting to
> > the Linux kernel.
>
> I cannot talk for all distros (there are too many), but major desktop
> distributions do that. For the 1st few RCs of a new kernel version I
> will be adjusting Fedora/RISCV configuration based on whatever
> changes land.
>
> Of course looking at default defconfig is part of that process.
Yes, we cannot generalize that all distros use their own configs. Lot of
embedded users prefer Yocto and Buildroot which certainly depend on
Linux defconfigs.
>
> >
> > This is espicially true for RISC-V as it's new and constantly changing.
> >
> > >
> > > > > 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. You talk later about misinformation but this is
> > a blatent lie.
> >
> > > 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.
> >
> > What? How many people actually do this for embedded systems.
> >
> > I agree that if you really want to maximise it as much as you can you
> > will go to this effort, but I don't think most people do. I think we
> > all know that lots of times embedded Linux is just hacked until it
> > works and then shipped. In this case defaults are very important.
> >
> > >
> > > > 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?
> >
> > Anup shared benchmarking results indicating that this change has a 12%
> > performance decrease for everyone who uses the defconfig without
> > removing this change.
> >
> > That is everyone who doesn't decide to remove config options from the
> > default config supplied by the people who wrote the code are now stuck
> > with a large performance hit. Passing the buck and saying that people
> > should be changing the defconfig cannot be the right solution here.
> >
> > > 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?
> >
> > 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.
>
> I would prefer to have a separate config for debug (that's what we do in
That's what I had suggested in my first comment on Paul's patch but
he did not respond. Unfortunately, we are having this conversation here
after the patch was merged by Paul without any discussions.
(Refer, https://lkml.org/lkml/2019/11/22/2084)
I have also sent a follow-up patch to add debug defconfigs.
(Refer, https://lkml.org/lkml/2019/12/4/1411)
There are two major concerns here:
1. Linux development process not being followed
Like I mentioned, I had already commented on Paul's patch. He simply
ignored my concerns about performance impact. This is a bad trend being
established in Linux RISC-V development.
2. Generalizing that all distros use their own config
This generalization is not true for any architecture. In fact, there are
lot of users (and distros) across architectures who depend on Linux
defconfig for building kernel image.
> Fedora). Why not use config fragment here (e.g. call it debug.config like
> in powerpc)?
This would be an interesting thing to explore if it benefits everyone but
for now we need separate debug defconfigs.
>
> See:
> https://github.com/torvalds/linux/commit/c1bc6f93f95970f917caaac544a374862e84df52
> https://elinux.org/images/3/39/Managing-Linux-Kernel-Configurations-with-Config-Fragments-Darren-Hart-VMware.pdf
>
Regards,
Anup
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
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
On Thu, 2019-12-05 at 15:29 -0800, Alistair Francis wrote:
> 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....
Whoops, I left the dots to remind me to come back and double check
this, but then I forgot to remove them.
>
> > > 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.
Just to clarify, I am sorry that I upset you. I did not mean to do
that.
I do not appriate you saying that I am spreading misinformation,
espicially when there are numbers to back up the claim of slowing down
defconfig users.
Alistair
>
> > > > > 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
On Thu, Dec 5, 2019 at 8:46 PM Alistair Francis
<[email protected]> wrote:
>
> On Thu, 2019-12-05 at 15:29 -0800, Alistair Francis wrote:
> > 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....
>
> Whoops, I left the dots to remind me to come back and double check
> this, but then I forgot to remove them.
>
> >
> > > > 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.
>
> Just to clarify, I am sorry that I upset you. I did not mean to do
> that.
>
> I do not appriate you saying that I am spreading misinformation,
> espicially when there are numbers to back up the claim of slowing down
> defconfig users.
>
> Alistair
>
> >
> > > > > > 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
Folks, isn't viable having a defconfig and a defconfig_debug. This
would address both cases and avoid putting a penalty on people that
are already using Risc-V boards or VMs for building software.
--
________________________________________
Carlos Eduardo de Paula
[email protected]
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
On Sat, Dec 7, 2019 at 2:42 AM Carlos Eduardo de Paula <[email protected]> wrote:
>
> On Thu, Dec 5, 2019 at 8:46 PM Alistair Francis
> <[email protected]> wrote:
> >
> > On Thu, 2019-12-05 at 15:29 -0800, Alistair Francis wrote:
> > > 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....
> >
> > Whoops, I left the dots to remind me to come back and double check
> > this, but then I forgot to remove them.
> >
> > >
> > > > > 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.
> >
> > Just to clarify, I am sorry that I upset you. I did not mean to do
> > that.
> >
> > I do not appriate you saying that I am spreading misinformation,
> > espicially when there are numbers to back up the claim of slowing down
> > defconfig users.
> >
> > Alistair
> >
> > >
> > > > > > > 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
>
> Folks, isn't viable having a defconfig and a defconfig_debug. This
> would address both cases and avoid putting a penalty on people that
> are already using Risc-V boards or VMs for building software.
Having defconfig and debug_defconfig will result is very similar defconfigs.
Better approach is to have a fragmented .config for extra DEBUG options.
Here's link to my patch for fragmented debug.config (please review):
https://lkml.org/lkml/2019/12/5/614
Regards,
Anup
On Fri, Dec 6, 2019 at 6:15 PM Anup Patel <[email protected]> wrote:
>
> On Sat, Dec 7, 2019 at 2:42 AM Carlos Eduardo de Paula <[email protected]> wrote:
> >
> > On Thu, Dec 5, 2019 at 8:46 PM Alistair Francis
> > <[email protected]> wrote:
> > >
> > > On Thu, 2019-12-05 at 15:29 -0800, Alistair Francis wrote:
> > > > 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....
> > >
> > > Whoops, I left the dots to remind me to come back and double check
> > > this, but then I forgot to remove them.
> > >
> > > >
> > > > > > 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.
> > >
> > > Just to clarify, I am sorry that I upset you. I did not mean to do
> > > that.
> > >
> > > I do not appriate you saying that I am spreading misinformation,
> > > espicially when there are numbers to back up the claim of slowing down
> > > defconfig users.
> > >
> > > Alistair
> > >
> > > >
> > > > > > > > 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
> >
> > Folks, isn't viable having a defconfig and a defconfig_debug. This
> > would address both cases and avoid putting a penalty on people that
> > are already using Risc-V boards or VMs for building software.
>
> Having defconfig and debug_defconfig will result is very similar defconfigs.
>
> Better approach is to have a fragmented .config for extra DEBUG options.
>
> Here's link to my patch for fragmented debug.config (please review):
> https://lkml.org/lkml/2019/12/5/614
>
> Regards,
> Anup
That's great and solves both cases.
Thanks Anup!
--
________________________________________
Carlos Eduardo de Paula
[email protected]
http://carlosedp.com
http://twitter.com/carlosedp
Linkedin
________________________________________
On Fri, Dec 6, 2019 at 1:15 PM Anup Patel <[email protected]> wrote:
>
> Better approach is to have a fragmented .config for extra DEBUG options.
Guys, stop this silly thread already.
The fact is, defconfig is useful for basic smoke testing - automated
compile and boot testing, and getting perhaps random people to test
something.
But it is not appropriate for a distro to use. Anybody who makes that
argument is wrong. If you actually know what you are doing, the
defconfig is entirely irrelevant, and no, trying to make special debug
fragments isn't going to make it more so.
So if you are a RISC-V distro: stop using the defconfig. You shouldn't
have used it in the first place. It's not meant to be a usable one.
And no, don't start making "more defconfigs". We've had that mess too.
It's broken too.
If you are a distro maintainer and you cannot be bothered to make your
own config file, then you should just stop being a distro maintainer,
and maybe take up farming instead.
Right now you guys are just wasting everybody elses time. Stop it.
Or at least remove me from the cc, because I'm not interested in this
whiny "I'm too lazy to maintain my own config, and I _insist_ that the
defconfig is meant only for me".
Linus