Re: Ingo, no more kconfig patches

Ingo Molnar
2008-05-03T21:03:47Z

* 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