0001 # Cumulative Kconfig recursive issue
0002 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0003 #
0004 # Test with:
0005 #
0006 # make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
0007 #
0008 # The recursive limitations with Kconfig has some non intuitive implications on
0009 # kconfig semantics which are documented here. One known practical implication
0010 # of the recursive limitation is that drivers cannot negate features from other
0011 # drivers if they share a common core requirement and use disjoint semantics to
0012 # annotate those requirements, ie, some drivers use "depends on" while others
0013 # use "select". For instance it means if a driver A and driver B share the same
0014 # core requirement, and one uses "select" while the other uses "depends on" to
0015 # annotate this, all features that driver A selects cannot now be negated by
0016 # driver B.
0017 #
0018 # A perhaps not so obvious implication of this is that, if semantics on these
0019 # core requirements are not carefully synced, as drivers evolve features
0020 # they select or depend on end up becoming shared requirements which cannot be
0021 # negated by other drivers.
0022 #
0023 # The example provided in Documentation/kbuild/Kconfig.recursion-issue-02
0024 # describes a simple driver core layout of example features a kernel might
0025 # have. Let's assume we have some CORE functionality, then the kernel has a
0026 # series of bells and whistles it desires to implement, its not so advanced so
0027 # it only supports bells at this time: CORE_BELL_A and CORE_BELL_B. If
0028 # CORE_BELL_A has some advanced feature CORE_BELL_A_ADVANCED which selects
0029 # CORE_BELL_A then CORE_BELL_A ends up becoming a common BELL feature which
0030 # other bells in the system cannot negate. The reason for this issue is
0031 # due to the disjoint use of semantics on expressing each bell's relationship
0032 # with CORE, one uses "depends on" while the other uses "select". Another
0033 # more important reason is that kconfig does not check for dependencies listed
0034 # under 'select' for a symbol, when such symbols are selected kconfig them
0035 # as mandatory required symbols. For more details on the heavy handed nature
0036 # of select refer to Documentation/kbuild/Kconfig.select-break
0037 #
0038 # To fix this the "depends on CORE" must be changed to "select CORE", or the
0039 # "select CORE" must be changed to "depends on CORE".
0040 #
0041 # For an example real world scenario issue refer to the attempt to remove
0042 # "select FW_LOADER" [0], in the end the simple alternative solution to this
0043 # problem consisted on matching semantics with newly introduced features.
0044 #
0045 # [0] https://lore.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com
0046
0047 mainmenu "Simple example to demo cumulative kconfig recursive dependency implication"
0048
0049 config CORE
0050 tristate
0051
0052 config CORE_BELL_A
0053 tristate
0054 depends on CORE
0055
0056 config CORE_BELL_A_ADVANCED
0057 tristate
0058 select CORE_BELL_A
0059
0060 config CORE_BELL_B
0061 tristate
0062 depends on !CORE_BELL_A
0063 select CORE
