lkml.org 
[lkml]   [2007]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: kconfig select warnings bogus?
    Satyam Sharma wrote:
    > I was only answering your *completely misplaced and
    > incorrect* original comment against the patch where you claimed
    > that the patch was "totally wrong" because of the way it removed
    > the "select" ... etc ...

    I believe I have explained why I labeled it as totally wrong.

    > And remember, like I said already, the whole _idea_ is such arch-
    > specific helper code be not mentioned from arch-agnostic Kconfig
    > files. You may not like it, but this is the standard / most common way
    > such cases are handled for tons of other cases in arch/...

    The standard and maintainable way (for drivers at least) is

    config A
    bool-or-tristate "option A"
    depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X

    It is not a matter of me disliking something. It's a matter of that we
    can easily determine what A needs, but have a hard time to determine and
    maintain the dependencies in the reverse way.

    BTW, if A needs platform-specific helper N, then A is not
    platform-agnostic. If A is desired to be platform-agnostic, then either
    A has to be implemented independently of N or N has to be made available
    on all platforms.

    > Which is why Adrian's way of solving this (shifting all such
    > arch-specific helper symbols also to drivers/... and then using depends
    > on select on it) is not viable.

    I'm not advocating any specific fixes or pseudo-fixes. I'm advocating
    the notation of dependencies in the direction "A requires B".

    Since you mention "select": My opinion about the "select" dialect of
    "depends on" is that the UIs should be improved and "select" should be
    removed from the Kconfig language. What do we "select"? Typically we
    "select" an option on which /n/ other options depend on but which itself
    does depend on none or few options higher up. The UIs could be able to
    figure this out for themselves, or if necessary by a hint tacked onto
    library-type options. That is, instead of

    config A
    tristate "driver A"
    select L

    config B
    tristate "driver B"
    select L

    config L
    tristate "library L"

    write

    config A
    tristate "driver A"
    depends on L

    config B
    tristate "driver B"
    depends on L

    config L
    tristate "library L"
    hint THIS_IS_A_LIBRARY

    Now let UIs "make oldconfig", "make menuconfig", "make randconfig" deal
    with the hint or ignore the hint --- according to the purpose and
    usability requirements of the respective UI. The "hint
    THIS_IS_SOMETHING" isn't even necessary in many cases to detect roles of
    options, because their position in the dependency graph is already
    saying something about it.

    These things really should be shifted into the UIs as much as possible,
    because we can have a number of special-purpose UIs but we want
    all-purpose Kconfig files.
    --
    Stefan Richter
    -=====-=-=== -=-= =-=--
    http://arcgraph.de/sr/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-20 15:13    [W:0.028 / U:34.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site