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?
    On Sun, May 20, 2007 at 03:09:10PM +0200, Stefan Richter wrote:
    >...
    > 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.
    >...

    Example where your proposal wouldn't work well:

    config MIPS_ATLAS
    bool "MIPS Atlas board"
    select SYS_SUPPORTS_LITTLE_ENDIAN
    select SYS_SUPPORTS_BIG_ENDIAN

    config SYS_SUPPORTS_BIG_ENDIAN
    bool

    config CPU_BIG_ENDIAN
    bool "Big endian"
    depends on SYS_SUPPORTS_BIG_ENDIAN


    Where's the value of allowing an UI to ignore hints? If an UI would
    ignore all hints on SYS_SUPPORTS_BIG_ENDIAN you would no longer be able
    to configure a kernel on this architecture.

    And there's no way for an UI to figure out the direction of the options -
    with "select" the only reasonable direction is fixed for all UIs.

    "select" might have room for improvements especially in the area of
    dependencies of select'ed options, but replacing it with overloading
    "depends on" plus hints wouldn't be a good solution.

    > Stefan Richter

    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@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 20:25    [W:0.026 / U:119.788 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site