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 semantics 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] https://lore.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
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.