Re: Ingo, no more kconfig patches

[Adrian Bunk]

On Sat, May 03, 2008 at 09:14:45PM +0200, Ingo Molnar wrote:
> 
> * Adrian Bunk <bunk@xxxxxxxxx> wrote:
> 
> > On Thu, May 01, 2008 at 04:52:34AM +0200, Ingo Molnar wrote:
> > > 
> > > * Adrian Bunk <bunk@xxxxxxxxxx> wrote:
> > > 
> > > > I would really appreciate it if you could send the error message 
> > > > and the .config but not quick kconfig patches that are often wrong 
> > > > and that you try to push through the maintainers as you tried 
> > > > here.
> > > 
> > > hey, sorry about invading your turf of trivial patches ;) I dont see 
> > > it as a problem that the thought process and the initial patch is 
> > > incomplete and ad-hoc. My preference is to work with people out in 
> > > the open, even on trivial issues. Dmitry is a capable maintainer who 
> > > understands his code very well and he'll resist me if i'm full of 
> > > it. Just like i resisted you when you were full of it. That's what 
> > > maintainers do, their job is to know their code.
> > > 
> > > And, occasionally, as in this case, i might end up being faced with 
> > > a bug in the code i maintain ;)
> > 
> > You completely miss my point.
> > 
> > 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.

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

Why can't you admit the patch you tried to push 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.

> Would you like to volunteer for that? It would be a _very_ useful 
> contribution. One such fix could avoid hundreds or even thousands of 
> trivial problems in the future - it could avoid having to make hundreds 
> or thousands of trivial patches in the future.

Different to you I actually have some basic understanding how kconfig 
works.

I'm not even sure the semantics of "select follows dependencies" 
would actually be better than what we have today.

> 	Ingo

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/