Documentation/kbuild/Kconfig.recursion-issue-02

   1 # Cumulative Kconfig recursive issue
   2 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3 #
   4 # Test with:
   5 #
   6 # make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
   7 #
   8 # The recursive limitations with Kconfig has some non intuitive implications on
   9 # kconfig sematics which are documented here. One known practical implication
  10 # of the recursive limitation is that drivers cannot negate features from other
  11 # drivers if they share a common core requirement and use disjoint semantics to
  12 # annotate those requirements, ie, some drivers use "depends on" while others
  13 # use "select". For instance it means if a driver A and driver B share the same
  14 # core requirement, and one uses "select" while the other uses "depends on" to
  15 # annotate this, all features that driver A selects cannot now be negated by
  16 # driver B.
  17 #
  18 # A perhaps not so obvious implication of this is that, if semantics on these
  19 # core requirements are not carefully synced, as drivers evolve features
  20 # they select or depend on end up becoming shared requirements which cannot be
  21 # negated by other drivers.
  22 #
  23 # The example provided in Documentation/kbuild/Kconfig.recursion-issue-02
  24 # describes a simple driver core layout of example features a kernel might
  25 # have. Let's assume we have some CORE functionality, then the kernel has a
  26 # series of bells and whistles it desires to implement, its not so advanced so
  27 # it only supports bells at this time: CORE_BELL_A and CORE_BELL_B. If
  28 # CORE_BELL_A has some advanced feature CORE_BELL_A_ADVANCED which selects
  29 # CORE_BELL_A then CORE_BELL_A ends up becoming a common BELL feature which
  30 # other bells in the system cannot negate. The reason for this issue is
  31 # due to the disjoint use of semantics on expressing each bell's relationship
  32 # with CORE, one uses "depends on" while the other uses "select". Another
  33 # more important reason is that kconfig does not check for dependencies listed
  34 # under 'select' for a symbol, when such symbols are selected kconfig them
  35 # as mandatory required symbols. For more details on the heavy handed nature
  36 # of select refer to Documentation/kbuild/Kconfig.select-break
  37 #
  38 # To fix this the "depends on CORE" must be changed to "select CORE", or the
  39 # "select CORE" must be changed to "depends on CORE".
  40 #
  41 # For an example real world scenario issue refer to the attempt to remove
  42 # "select FW_LOADER" [0], in the end the simple alternative solution to this
  43 # problem consisted on matching semantics with newly introduced features.
  44 #
  45 # [0] http://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com
  46
  47 mainmenu "Simple example to demo cumulative kconfig recursive dependency implication"
  48
  49 config CORE
  50         tristate
  51
  52 config CORE_BELL_A
  53         tristate
  54         depends on CORE
  55
  56 config CORE_BELL_A_ADVANCED
  57         tristate
  58         select CORE_BELL_A
  59
  60 config CORE_BELL_B
  61         tristate
  62         depends on !CORE_BELL_A
  63         select CORE