lkml.org 
[lkml]   [2008]   [May]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 3 May 2008 21:14:45 +0200
FromIngo Molnar <>
SubjectRe: Ingo, no more kconfig patches
* Adrian Bunk <bunk@stusta.de> wrote:

> On Thu, May 01, 2008 at 04:52:34AM +0200, Ingo Molnar wrote:
> > > > * Adrian Bunk <bunk@kernel.org> 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.

As Sam said it, fixing that Kconfig design bug would be "nice" - but 
unfortunately the Kconfig subsystem is not actively developed anymore. 
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.

	Ingo


\
 
 \ /
  Last update: 2008-05-03 21:17    [from the cache]
©2003-2008