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