1================
2Kconfig Language
3================
4
5Introduction
6------------
7
8The configuration database is a collection of configuration options
9organized in a tree structure::
10
11	+- Code maturity level options
12	|  +- Prompt for development and/or incomplete code/drivers
13	+- General setup
14	|  +- Networking support
15	|  +- System V IPC
16	|  +- BSD Process Accounting
17	|  +- Sysctl support
18	+- Loadable module support
19	|  +- Enable loadable module support
20	|     +- Set version information on all module symbols
21	|     +- Kernel module loader
22	+- ...
23
24Every entry has its own dependencies. These dependencies are used
25to determine the visibility of an entry. Any child entry is only
26visible if its parent entry is also visible.
27
28Menu entries
29------------
30
31Most entries define a config option; all other entries help to organize
32them. A single configuration option is defined like this::
33
34  config MODVERSIONS
35	bool "Set version information on all module symbols"
36	depends on MODULES
37	help
38	  Usually, modules have to be recompiled whenever you switch to a new
39	  kernel.  ...
40
41Every line starts with a key word and can be followed by multiple
42arguments.  "config" starts a new config entry. The following lines
43define attributes for this config option. Attributes can be the type of
44the config option, input prompt, dependencies, help text and default
45values. A config option can be defined multiple times with the same
46name, but every definition can have only a single input prompt and the
47type must not conflict.
48
49Menu attributes
50---------------
51
52A menu entry can have a number of attributes. Not all of them are
53applicable everywhere (see syntax).
54
55- type definition: "bool"/"tristate"/"string"/"hex"/"int"
56
57  Every config option must have a type. There are only two basic types:
58  tristate and string; the other types are based on these two. The type
59  definition optionally accepts an input prompt, so these two examples
60  are equivalent::
61
62	bool "Networking support"
63
64  and::
65
66	bool
67	prompt "Networking support"
68
69- input prompt: "prompt" <prompt> ["if" <expr>]
70
71  Every menu entry can have at most one prompt, which is used to display
72  to the user. Optionally dependencies only for this prompt can be added
73  with "if".
74
75- default value: "default" <expr> ["if" <expr>]
76
77  A config option can have any number of default values. If multiple
78  default values are visible, only the first defined one is active.
79  Default values are not limited to the menu entry where they are
80  defined. This means the default can be defined somewhere else or be
81  overridden by an earlier definition.
82  The default value is only assigned to the config symbol if no other
83  value was set by the user (via the input prompt above). If an input
84  prompt is visible the default value is presented to the user and can
85  be overridden by him.
86  Optionally, dependencies only for this default value can be added with
87  "if".
88
89 The default value deliberately defaults to 'n' in order to avoid bloating the
90 build. With few exceptions, new config options should not change this. The
91 intent is for "make oldconfig" to add as little as possible to the config from
92 release to release.
93
94 Note:
95	Things that merit "default y/m" include:
96
97	a) A new Kconfig option for something that used to always be built
98	   should be "default y".
99
100	b) A new gatekeeping Kconfig option that hides/shows other Kconfig
101	   options (but does not generate any code of its own), should be
102	   "default y" so people will see those other options.
103
104	c) Sub-driver behavior or similar options for a driver that is
105	   "default n". This allows you to provide sane defaults.
106
107	d) Hardware or infrastructure that everybody expects, such as CONFIG_NET
108	   or CONFIG_BLOCK. These are rare exceptions.
109
110- type definition + default value::
111
112	"def_bool"/"def_tristate" <expr> ["if" <expr>]
113
114  This is a shorthand notation for a type definition plus a value.
115  Optionally dependencies for this default value can be added with "if".
116
117- dependencies: "depends on" <expr>
118
119  This defines a dependency for this menu entry. If multiple
120  dependencies are defined, they are connected with '&&'. Dependencies
121  are applied to all other options within this menu entry (which also
122  accept an "if" expression), so these two examples are equivalent::
123
124	bool "foo" if BAR
125	default y if BAR
126
127  and::
128
129	depends on BAR
130	bool "foo"
131	default y
132
133- reverse dependencies: "select" <symbol> ["if" <expr>]
134
135  While normal dependencies reduce the upper limit of a symbol (see
136  below), reverse dependencies can be used to force a lower limit of
137  another symbol. The value of the current menu symbol is used as the
138  minimal value <symbol> can be set to. If <symbol> is selected multiple
139  times, the limit is set to the largest selection.
140  Reverse dependencies can only be used with boolean or tristate
141  symbols.
142
143  Note:
144	select should be used with care. select will force
145	a symbol to a value without visiting the dependencies.
146	By abusing select you are able to select a symbol FOO even
147	if FOO depends on BAR that is not set.
148	In general use select only for non-visible symbols
149	(no prompts anywhere) and for symbols with no dependencies.
150	That will limit the usefulness but on the other hand avoid
151	the illegal configurations all over.
152
153- weak reverse dependencies: "imply" <symbol> ["if" <expr>]
154
155  This is similar to "select" as it enforces a lower limit on another
156  symbol except that the "implied" symbol's value may still be set to n
157  from a direct dependency or with a visible prompt.
158
159  Given the following example::
160
161    config FOO
162	tristate "foo"
163	imply BAZ
164
165    config BAZ
166	tristate "baz"
167	depends on BAR
168
169  The following values are possible:
170
171	===		===		=============	==============
172	FOO		BAR		BAZ's default	choice for BAZ
173	===		===		=============	==============
174	n		y		n		N/m/y
175	m		y		m		M/y/n
176	y		y		y		Y/m/n
177	n		m		n		N/m
178	m		m		m		M/n
179	y		m		m		M/n
180	y		n		*		N
181	===		===		=============	==============
182
183  This is useful e.g. with multiple drivers that want to indicate their
184  ability to hook into a secondary subsystem while allowing the user to
185  configure that subsystem out without also having to unset these drivers.
186
187  Note: If the combination of FOO=y and BAR=m causes a link error,
188  you can guard the function call with IS_REACHABLE()::
189
190	foo_init()
191	{
192		if (IS_REACHABLE(CONFIG_BAZ))
193			baz_register(&foo);
194		...
195	}
196
197  Note: If the feature provided by BAZ is highly desirable for FOO,
198  FOO should imply not only BAZ, but also its dependency BAR::
199
200    config FOO
201	tristate "foo"
202	imply BAR
203	imply BAZ
204
205- limiting menu display: "visible if" <expr>
206
207  This attribute is only applicable to menu blocks, if the condition is
208  false, the menu block is not displayed to the user (the symbols
209  contained there can still be selected by other symbols, though). It is
210  similar to a conditional "prompt" attribute for individual menu
211  entries. Default value of "visible" is true.
212
213- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
214
215  This allows to limit the range of possible input values for int
216  and hex symbols. The user can only input a value which is larger than
217  or equal to the first symbol and smaller than or equal to the second
218  symbol.
219
220- help text: "help"
221
222  This defines a help text. The end of the help text is determined by
223  the indentation level, this means it ends at the first line which has
224  a smaller indentation than the first line of the help text.
225
226- module attribute: "modules"
227  This declares the symbol to be used as the MODULES symbol, which
228  enables the third modular state for all config symbols.
229  At most one symbol may have the "modules" option set.
230
231Menu dependencies
232-----------------
233
234Dependencies define the visibility of a menu entry and can also reduce
235the input range of tristate symbols. The tristate logic used in the
236expressions uses one more state than normal boolean logic to express the
237module state. Dependency expressions have the following syntax::
238
239  <expr> ::= <symbol>                           (1)
240           <symbol> '=' <symbol>                (2)
241           <symbol> '!=' <symbol>               (3)
242           <symbol1> '<' <symbol2>              (4)
243           <symbol1> '>' <symbol2>              (4)
244           <symbol1> '<=' <symbol2>             (4)
245           <symbol1> '>=' <symbol2>             (4)
246           '(' <expr> ')'                       (5)
247           '!' <expr>                           (6)
248           <expr> '&&' <expr>                   (7)
249           <expr> '||' <expr>                   (8)
250
251Expressions are listed in decreasing order of precedence.
252
253(1) Convert the symbol into an expression. Boolean and tristate symbols
254    are simply converted into the respective expression values. All
255    other symbol types result in 'n'.
256(2) If the values of both symbols are equal, it returns 'y',
257    otherwise 'n'.
258(3) If the values of both symbols are equal, it returns 'n',
259    otherwise 'y'.
260(4) If value of <symbol1> is respectively lower, greater, lower-or-equal,
261    or greater-or-equal than value of <symbol2>, it returns 'y',
262    otherwise 'n'.
263(5) Returns the value of the expression. Used to override precedence.
264(6) Returns the result of (2-/expr/).
265(7) Returns the result of min(/expr/, /expr/).
266(8) Returns the result of max(/expr/, /expr/).
267
268An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
269respectively for calculations). A menu entry becomes visible when its
270expression evaluates to 'm' or 'y'.
271
272There are two types of symbols: constant and non-constant symbols.
273Non-constant symbols are the most common ones and are defined with the
274'config' statement. Non-constant symbols consist entirely of alphanumeric
275characters or underscores.
276Constant symbols are only part of expressions. Constant symbols are
277always surrounded by single or double quotes. Within the quote, any
278other character is allowed and the quotes can be escaped using '\'.
279
280Menu structure
281--------------
282
283The position of a menu entry in the tree is determined in two ways. First
284it can be specified explicitly::
285
286  menu "Network device support"
287	depends on NET
288
289  config NETDEVICES
290	...
291
292  endmenu
293
294All entries within the "menu" ... "endmenu" block become a submenu of
295"Network device support". All subentries inherit the dependencies from
296the menu entry, e.g. this means the dependency "NET" is added to the
297dependency list of the config option NETDEVICES.
298
299The other way to generate the menu structure is done by analyzing the
300dependencies. If a menu entry somehow depends on the previous entry, it
301can be made a submenu of it. First, the previous (parent) symbol must
302be part of the dependency list and then one of these two conditions
303must be true:
304
305- the child entry must become invisible, if the parent is set to 'n'
306- the child entry must only be visible, if the parent is visible::
307
308    config MODULES
309	bool "Enable loadable module support"
310
311    config MODVERSIONS
312	bool "Set version information on all module symbols"
313	depends on MODULES
314
315    comment "module support disabled"
316	depends on !MODULES
317
318MODVERSIONS directly depends on MODULES, this means it's only visible if
319MODULES is different from 'n'. The comment on the other hand is only
320visible when MODULES is set to 'n'.
321
322
323Kconfig syntax
324--------------
325
326The configuration file describes a series of menu entries, where every
327line starts with a keyword (except help texts). The following keywords
328end a menu entry:
329
330- config
331- menuconfig
332- choice/endchoice
333- comment
334- menu/endmenu
335- if/endif
336- source
337
338The first five also start the definition of a menu entry.
339
340config::
341
342	"config" <symbol>
343	<config options>
344
345This defines a config symbol <symbol> and accepts any of above
346attributes as options.
347
348menuconfig::
349
350	"menuconfig" <symbol>
351	<config options>
352
353This is similar to the simple config entry above, but it also gives a
354hint to front ends, that all suboptions should be displayed as a
355separate list of options. To make sure all the suboptions will really
356show up under the menuconfig entry and not outside of it, every item
357from the <config options> list must depend on the menuconfig symbol.
358In practice, this is achieved by using one of the next two constructs::
359
360  (1):
361  menuconfig M
362  if M
363      config C1
364      config C2
365  endif
366
367  (2):
368  menuconfig M
369  config C1
370      depends on M
371  config C2
372      depends on M
373
374In the following examples (3) and (4), C1 and C2 still have the M
375dependency, but will not appear under menuconfig M anymore, because
376of C0, which doesn't depend on M::
377
378  (3):
379  menuconfig M
380      config C0
381  if M
382      config C1
383      config C2
384  endif
385
386  (4):
387  menuconfig M
388  config C0
389  config C1
390      depends on M
391  config C2
392      depends on M
393
394choices::
395
396	"choice" [symbol]
397	<choice options>
398	<choice block>
399	"endchoice"
400
401This defines a choice group and accepts any of the above attributes as
402options. A choice can only be of type bool or tristate.  If no type is
403specified for a choice, its type will be determined by the type of
404the first choice element in the group or remain unknown if none of the
405choice elements have a type specified, as well.
406
407While a boolean choice only allows a single config entry to be
408selected, a tristate choice also allows any number of config entries
409to be set to 'm'. This can be used if multiple drivers for a single
410hardware exists and only a single driver can be compiled/loaded into
411the kernel, but all drivers can be compiled as modules.
412
413A choice accepts another option "optional", which allows to set the
414choice to 'n' and no entry needs to be selected.
415If no [symbol] is associated with a choice, then you can not have multiple
416definitions of that choice. If a [symbol] is associated to the choice,
417then you may define the same choice (i.e. with the same entries) in another
418place.
419
420comment::
421
422	"comment" <prompt>
423	<comment options>
424
425This defines a comment which is displayed to the user during the
426configuration process and is also echoed to the output files. The only
427possible options are dependencies.
428
429menu::
430
431	"menu" <prompt>
432	<menu options>
433	<menu block>
434	"endmenu"
435
436This defines a menu block, see "Menu structure" above for more
437information. The only possible options are dependencies and "visible"
438attributes.
439
440if::
441
442	"if" <expr>
443	<if block>
444	"endif"
445
446This defines an if block. The dependency expression <expr> is appended
447to all enclosed menu entries.
448
449source::
450
451	"source" <prompt>
452
453This reads the specified configuration file. This file is always parsed.
454
455mainmenu::
456
457	"mainmenu" <prompt>
458
459This sets the config program's title bar if the config program chooses
460to use it. It should be placed at the top of the configuration, before any
461other statement.
462
463'#' Kconfig source file comment:
464
465An unquoted '#' character anywhere in a source file line indicates
466the beginning of a source file comment.  The remainder of that line
467is a comment.
468
469
470Kconfig hints
471-------------
472This is a collection of Kconfig tips, most of which aren't obvious at
473first glance and most of which have become idioms in several Kconfig
474files.
475
476Adding common features and make the usage configurable
477~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
478It is a common idiom to implement a feature/functionality that are
479relevant for some architectures but not all.
480The recommended way to do so is to use a config variable named HAVE_*
481that is defined in a common Kconfig file and selected by the relevant
482architectures.
483An example is the generic IOMAP functionality.
484
485We would in lib/Kconfig see::
486
487  # Generic IOMAP is used to ...
488  config HAVE_GENERIC_IOMAP
489
490  config GENERIC_IOMAP
491	depends on HAVE_GENERIC_IOMAP && FOO
492
493And in lib/Makefile we would see::
494
495	obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
496
497For each architecture using the generic IOMAP functionality we would see::
498
499  config X86
500	select ...
501	select HAVE_GENERIC_IOMAP
502	select ...
503
504Note: we use the existing config option and avoid creating a new
505config variable to select HAVE_GENERIC_IOMAP.
506
507Note: the use of the internal config variable HAVE_GENERIC_IOMAP, it is
508introduced to overcome the limitation of select which will force a
509config option to 'y' no matter the dependencies.
510The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
511situation where select forces a symbol equals to 'y'.
512
513Adding features that need compiler support
514~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
515
516There are several features that need compiler support. The recommended way
517to describe the dependency on the compiler feature is to use "depends on"
518followed by a test macro::
519
520  config STACKPROTECTOR
521	bool "Stack Protector buffer overflow detection"
522	depends on $(cc-option,-fstack-protector)
523	...
524
525If you need to expose a compiler capability to makefiles and/or C source files,
526`CC_HAS_` is the recommended prefix for the config option::
527
528  config CC_HAS_FOO
529	def_bool $(success,$(srctree)/scripts/cc-check-foo.sh $(CC))
530
531Build as module only
532~~~~~~~~~~~~~~~~~~~~
533To restrict a component build to module-only, qualify its config symbol
534with "depends on m".  E.g.::
535
536  config FOO
537	depends on BAR && m
538
539limits FOO to module (=m) or disabled (=n).
540
541Compile-testing
542~~~~~~~~~~~~~~~
543If a config symbol has a dependency, but the code controlled by the config
544symbol can still be compiled if the dependency is not met, it is encouraged to
545increase build coverage by adding an "|| COMPILE_TEST" clause to the
546dependency. This is especially useful for drivers for more exotic hardware, as
547it allows continuous-integration systems to compile-test the code on a more
548common system, and detect bugs that way.
549Note that compile-tested code should avoid crashing when run on a system where
550the dependency is not met.
551
552Architecture and platform dependencies
553~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
554Due to the presence of stubs, most drivers can now be compiled on most
555architectures. However, this does not mean it makes sense to have all drivers
556available everywhere, as the actual hardware may only exist on specific
557architectures and platforms. This is especially true for on-SoC IP cores,
558which may be limited to a specific vendor or SoC family.
559
560To prevent asking the user about drivers that cannot be used on the system(s)
561the user is compiling a kernel for, and if it makes sense, config symbols
562controlling the compilation of a driver should contain proper dependencies,
563limiting the visibility of the symbol to (a superset of) the platform(s) the
564driver can be used on. The dependency can be an architecture (e.g. ARM) or
565platform (e.g. ARCH_OMAP4) dependency. This makes life simpler not only for
566distro config owners, but also for every single developer or user who
567configures a kernel.
568
569Such a dependency can be relaxed by combining it with the compile-testing rule
570above, leading to:
571
572  config FOO
573	bool "Support for foo hardware"
574	depends on ARCH_FOO_VENDOR || COMPILE_TEST
575
576Kconfig recursive dependency limitations
577~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
578
579If you've hit the Kconfig error: "recursive dependency detected" you've run
580into a recursive dependency issue with Kconfig, a recursive dependency can be
581summarized as a circular dependency. The kconfig tools need to ensure that
582Kconfig files comply with specified configuration requirements. In order to do
583that kconfig must determine the values that are possible for all Kconfig
584symbols, this is currently not possible if there is a circular relation
585between two or more Kconfig symbols. For more details refer to the "Simple
586Kconfig recursive issue" subsection below. Kconfig does not do recursive
587dependency resolution; this has a few implications for Kconfig file writers.
588We'll first explain why this issues exists and then provide an example
589technical limitation which this brings upon Kconfig developers. Eager
590developers wishing to try to address this limitation should read the next
591subsections.
592
593Simple Kconfig recursive issue
594~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
595
596Read: Documentation/kbuild/Kconfig.recursion-issue-01
597
598Test with::
599
600  make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig
601
602Cumulative Kconfig recursive issue
603~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
604
605Read: Documentation/kbuild/Kconfig.recursion-issue-02
606
607Test with::
608
609  make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
610
611Practical solutions to kconfig recursive issue
612~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
613
614Developers who run into the recursive Kconfig issue have two options
615at their disposal. We document them below and also provide a list of
616historical issues resolved through these different solutions.
617
618  a) Remove any superfluous "select FOO" or "depends on FOO"
619  b) Match dependency semantics:
620
621	b1) Swap all "select FOO" to "depends on FOO" or,
622
623	b2) Swap all "depends on FOO" to "select FOO"
624
625The resolution to a) can be tested with the sample Kconfig file
626Documentation/kbuild/Kconfig.recursion-issue-01 through the removal
627of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already
628since CORE_BELL_A depends on CORE. At times it may not be possible to remove
629some dependency criteria, for such cases you can work with solution b).
630
631The two different resolutions for b) can be tested in the sample Kconfig file
632Documentation/kbuild/Kconfig.recursion-issue-02.
633
634Below is a list of examples of prior fixes for these types of recursive issues;
635all errors appear to involve one or more "select" statements and one or more
636"depends on".
637
638============    ===================================
639commit          fix
640============    ===================================
64106b718c01208    select A -> depends on A
642c22eacfe82f9    depends on A -> depends on B
6436a91e854442c    select A -> depends on A
644118c565a8f2e    select A -> select B
645f004e5594705    select A -> depends on A
646c7861f37b4c6    depends on A -> (null)
64780c69915e5fb    select A -> (null)              (1)
648c2218e26c0d0    select A -> depends on A        (1)
649d6ae99d04e1c    select A -> depends on A
65095ca19cf8cbf    select A -> depends on A
6518f057d7bca54    depends on A -> (null)
6528f057d7bca54    depends on A -> select A
653a0701f04846e    select A -> depends on A
6540c8b92f7f259    depends on A -> (null)
655e4e9e0540928    select A -> depends on A        (2)
6567453ea886e87    depends on A > (null)           (1)
6577b1fff7e4fdf    select A -> depends on A
65886c747d2a4f0    select A -> depends on A
659d9f9ab51e55e    select A -> depends on A
6600c51a4d8abd6    depends on A -> select A        (3)
661e98062ed6dc4    select A -> depends on A        (3)
66291e5d284a7f1    select A -> (null)
663============    ===================================
664
665(1) Partial (or no) quote of error.
666(2) That seems to be the gist of that fix.
667(3) Same error.
668
669Future kconfig work
670~~~~~~~~~~~~~~~~~~~
671
672Work on kconfig is welcomed on both areas of clarifying semantics and on
673evaluating the use of a full SAT solver for it. A full SAT solver can be
674desirable to enable more complex dependency mappings and / or queries,
675for instance one possible use case for a SAT solver could be that of handling
676the current known recursive dependency issues. It is not known if this would
677address such issues but such evaluation is desirable. If support for a full SAT
678solver proves too complex or that it cannot address recursive dependency issues
679Kconfig should have at least clear and well defined semantics which also
680addresses and documents limitations or requirements such as the ones dealing
681with recursive dependencies.
682
683Further work on both of these areas is welcomed on Kconfig. We elaborate
684on both of these in the next two subsections.
685
686Semantics of Kconfig
687~~~~~~~~~~~~~~~~~~~~
688
689The use of Kconfig is broad, Linux is now only one of Kconfig's users:
690one study has completed a broad analysis of Kconfig use in 12 projects [0]_.
691Despite its widespread use, and although this document does a reasonable job
692in documenting basic Kconfig syntax a more precise definition of Kconfig
693semantics is welcomed. One project deduced Kconfig semantics through
694the use of the xconfig configurator [1]_. Work should be done to confirm if
695the deduced semantics matches our intended Kconfig design goals.
696Another project formalized a denotational semantics of a core subset of
697the Kconfig language [10]_.
698
699Having well defined semantics can be useful for tools for practical
700evaluation of dependencies, for instance one such case was work to
701express in boolean abstraction of the inferred semantics of Kconfig to
702translate Kconfig logic into boolean formulas and run a SAT solver on this to
703find dead code / features (always inactive), 114 dead features were found in
704Linux using this methodology [1]_ (Section 8: Threats to validity).
705The kismet tool, based on the semantics in [10]_, finds abuses of reverse
706dependencies and has led to dozens of committed fixes to Linux Kconfig files [11]_.
707
708Confirming this could prove useful as Kconfig stands as one of the leading
709industrial variability modeling languages [1]_ [2]_. Its study would help
710evaluate practical uses of such languages, their use was only theoretical
711and real world requirements were not well understood. As it stands though
712only reverse engineering techniques have been used to deduce semantics from
713variability modeling languages such as Kconfig [3]_.
714
715.. [0] https://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
716.. [1] https://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
717.. [2] https://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
718.. [3] https://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf
719
720Full SAT solver for Kconfig
721~~~~~~~~~~~~~~~~~~~~~~~~~~~
722
723Although SAT solvers [4]_ haven't yet been used by Kconfig directly, as noted
724in the previous subsection, work has been done however to express in boolean
725abstraction the inferred semantics of Kconfig to translate Kconfig logic into
726boolean formulas and run a SAT solver on it [5]_. Another known related project
727is CADOS [6]_ (former VAMOS [7]_) and the tools, mainly undertaker [8]_, which
728has been introduced first with [9]_.  The basic concept of undertaker is to
729extract variability models from Kconfig and put them together with a
730propositional formula extracted from CPP #ifdefs and build-rules into a SAT
731solver in order to find dead code, dead files, and dead symbols. If using a SAT
732solver is desirable on Kconfig one approach would be to evaluate repurposing
733such efforts somehow on Kconfig. There is enough interest from mentors of
734existing projects to not only help advise how to integrate this work upstream
735but also help maintain it long term. Interested developers should visit:
736
737https://kernelnewbies.org/KernelProjects/kconfig-sat
738
739.. [4] https://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf
740.. [5] https://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
741.. [6] https://cados.cs.fau.de
742.. [7] https://vamos.cs.fau.de
743.. [8] https://undertaker.cs.fau.de
744.. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf
745.. [10] https://paulgazzillo.com/papers/esecfse21.pdf
746.. [11] https://github.com/paulgazz/kmax
747