lkml.org 
[lkml]   [2007]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] select and dependencies in Kconfig
    Al Viro wrote:
    >> stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
    >> end up with unbuildable configs.
    >
    > BTW, this kind of situation happens often enough, so how about doing
    > the following: teach kconfig that if FOO selects BAR and BAR depends
    > on <expr>, we should act as if FOO had explicit depends on <expr>.

    "A... select B" is just a flavor of "A... depends on B", with the
    additional instruction to the Kconfig UIs: Don't hide A if you can
    silently switch on B.

    So, since it is just a flavor of 'depend on', it is very obvious that it
    has to propagate indirect dependencies just like 'depends on' does.

    [...]
    > the only thing I'm not sure how to deal
    > with is how to show such inherited dependencies in menuconfig et.al.

    How about throwing "select" out of the Kconfig language and improving
    the UIs instead, so that users find what they want and need?

    Compare to software package management. I think most of the package
    management systems store merely plain dependencies in the package
    metadata. The package manager UIs then allow users to auto-select all
    packages which package A depends on, show him what was selected, let him
    edit his choice before massive downloads, et cetera. Also, package
    manager UIs often offer some collections of typically used packages and
    so on. I don't think the package metadata already contain some
    instructions which stuff to pre-select for the user. It's all in the UIs.

    Back to Kconfig.

    We have

    - driver-like options which enable building of certain functionality.
    They often depend on multiple other options higher up, either by
    directly depending on one other option which itself may depend on
    others, or even by directly depending on several options (which each
    may depend others.)
    The driver-like options are the ones that are most relevant to users
    because they ultimately decide what the kernel can do.

    - Tunables which modify how those driver-like code will behave.

    - Infrastructure (subsystem cores), libraries.
    Nobody really cares about these on their own, we only want have all
    those of them built which serve above mentioned driver-like options.

    Did I forget anything?

    So, we put

    - metadata about kernel parts (what do they, what are their
    dependencies)
    into Kconfig files,

    - methods to produce .configs (which honor the dependencies and
    reflect which kernel functionality the user wanted)
    into "make fooconfig" programs,

    - user interfaces which control these methods
    into "make fooconfig" programs.

    The goal is to let the user safely and efficiently enable everything he
    needs/ disable everything he doesn't need.

    The question is: Which kind of information has to be put into the
    Kconfig files to achieve this objective --- besides the plain
    information about dependencies and human-readable information about the
    functionality of the options?

    Do we need instructions like "select" in Kconfig files, or do we rather
    need more powerful "make fooconfig" programs?

    PS: Actually, the problems with "select" which Al pointed out in the
    parent post show that "select" doesn't really let us get by with less
    powerful "make fooconfig" programs, because proper treatment of
    "depends" is sometimes nontrivial.

    PPS: Other current discussions indicate that additional metadata in the
    Kconfigs might perhaps be useful, e.g. metadata about a kernel part's
    lifecycle status (experimental, deprecated et al).
    --
    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-16 16:29    [W:0.029 / U:0.304 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site