lkml.org 
[lkml]   [2008]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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    [W:2.516 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site