Orange Pi5 kernel

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