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