Messages in this thread | | | Date | Thu, 5 Dec 2019 15:12:03 -0800 (PST) | From | Paul Walmsley <> | Subject | Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1 |
| |
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
| |