Re: Ingo, no more kconfig patches

[Ingo Molnar <mingo@elte.hu>]

* Adrian Bunk <bunk@kernel.org> wrote:

> > > You wrongly (and loudly) blamed Dmitry for something you broke 
> > > yourself.
> > 
> > i didnt. Read what i wrote:
> > 
> > || no, you are wrong, read the current Kconfig rules again. If the user 
> > || can create a .config that does not build, it is driver breakage. It 
> > || always was, and has been in the past 15 years.
> > ||
> > || Kconfig might be extended to make dependencies easier to manage for 
> > || developers but until that is implemented you have to craft your 
> > || driver's dependencies with the current tools in a way that doesnt 
> > || break the build.
> > 
> > and that's exactly what happens with Roman's patch: a Kconfig subsystem 
> > design bug (its inability to properly propagate the dependencies of 
> > select's) is worked around in the driver space: by the LEDS_CORE driver 
> > config introduction and no user-visible.
> > 
> > Roman's patch is obviously cleaner than my hack (i just fixed a single 
> > instantiation of the problem, while he changed the LEDS driver 
> > dependency structure), but it's still a workaround for a Kconfig 
> > subsystem bug and the same problem could reoccur elsewhere. It could hit 
> > anytime dual dependencies are introduced in a driver accidentally.
> 
> Ingo, perhaps it helps if I put it in caps:
> 
> YOU TRIED TO PUSH AN INPUT PATCH FOR AN X86 BUG.

Adrian, your tone is getting more and more abusive, and while i can 
easily ignore your abuse you are not just doing it towards me but 
towards other kernel developers as well. You need to stop that.

Yes, the incomplete (and buggy) select came from an x86 Kconfig file but 
you missed the real argument. Half a dozen other times similar bugs came 
from other portions of the tree so it's a reoccuring pattern of bugs.

And had you read the exchange more carefully you'd notice that the 
discussion was about the Kconfig subsystem bug which is causing all 
these other bugs - which Kconfig subsystem bug is still unfixed. In the 
discussion Dmitry assumed the obvious: that a select on a component will 
also select the sub-components. The problem is - select does not do 
that.

> Roman's patch is better than adding a select, but your patch would 
> have added the select in the completely wrong subsystem.

sure, and that's exactly what i said above: "Roman's patch is obviously 
cleaner than my hack". It avoids this problem by creating a single 
target to select for.

A wrong/buggy select _somewhere_ (this time the bug indeed was in an x86 
subarch Kconfig - but often it was just in a driver that tried to enable 
LEDS support) breaks the build - instead of propagating dependencies or 
at least warning about the problem. That's a Kconfig subsystem design 
bug and it has been known for years.

it's now worked around by Roman's patch by making the LEDS Kconfig 
structure simpler so there's just a single select target. But the root 
cause was not fixed and similar issues could hit the kernel anytime in 
the future. So it's not a real fix - it just prolonges the real fix some 
more.

> Why can't you admit the patch you tried to push was wrong?

how many times do i have to repeat it that yes it was a hack and that it 
was wrong?

> > As Sam said it, fixing that Kconfig design bug would be "nice" - but 
> > unfortunately the Kconfig subsystem is not actively developed 
> > anymore.
> 
> Roman is still active.

great, does this mean we'll see fixes for select's misbehavior, along 
the lines of Sam's suggestions?

at minimum a warning needs to be emitted by the kconfig tool if such 
incomplete selects are used. I've stopped counting the number of times 
such issues have broken the build and have held up kernel development. 

All the information is already in the Kconfig files for the kconfig 
tool/subsystem to make an intelligent decision. It's just not fully 
used, and the burden of fixing these problems is pushed back to the 
developers who create the Kconfig files.

	Ingo