| Age | Commit message (Collapse) | Author |
|---|
|
Some options that are hardware related, can either be built in or
modules, and meet the criteria of being acceptable for a BSP.
To allow these options to not throw warnings, we create a new
configuration fragment to go along with the 'hardware.cfg' and
'nonhardware.cfg' special fragments.
This new fragment is called 'y_or_m_enabled.cfg' and is effective
for the fragments in its directory. The format is the same as
hardware/nonhardware.cfg, is simply a list of CONFIG_ options.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The classification of fragments should go in the following order:
- kconf include <type>
- general .kcf group classification
- specific hardware.cfg/non-hardware.cfg
With our previous singe pass through the queue, it wasn't possible
to give the specific values the last say.
Doing two passes allows us to give the final say to a specific
classifcation.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The config.queue has typing hints inline with each fragment,
we should be using them to further classify the options, and
not only relying on the special hardware.cfg, etc, files that
are part of the meta data
We also should be checking for options that were set to a
non 'no' value, and that don't make it into the final .config,
since without that check it means we are missing some warnings.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
sys.exit(1) belongs to the error message above but has the wrong
indentation.
Signed-off-by: Sam Van Den Berge <sam.van.den.berge@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Being in both h/w and non-hardware leads us to results where we
can't easily silence a warning. So if we've added it to h/w we need
remove it from non-hardware. If we do it in both the hardware and
non hardware cases, the end result is that the last classification
wins, which is what we want.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
If there's a mismatch, and an option is in non-hardware AND hardware,
then it means that it was globally classified as non-hardware, but
had a hardware.cfg that re-classifed it.
We should report these errors with --classify is passed.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Commented lines that contained CONFIG_FOO ... were being picked up
as option lines and reported as invalid.
We make the regex more explicit and only match on spaces before
CONFIG_ to declare if a 'is not set' line is invalid.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
This large commit is a re-work of symbol why to not only explain
why a symbol is set to a value, but to be able to process and
entire configuration queue and fragments to perform extended
analsysis and configuration tracking.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Kconfiglib/* were under ISC license before they were imported
here from https://github.com/ulfalizer/Kconfiglib
Adjusting SPDX header to reflect that fact.
tools/* all have some sort of GPLv2 headers; adding SPDX header
to make it obvious.
This address bug #13334 :
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13334
Change-Id: I243f2dd266a398f982798b771e74a67be70ecb52
Signed-off-by: William Bourque <wbourque@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Add the script symbol_why to the kern-tools suite. This script takes
a .config, a kernel source directory and a configuration value as
inputs, and outputs a summary and/or conditional diagnostics on that
variable:
usage: symbol_why.py [-h] [-c DOTCONFIG] [-s KSRC] [-v] [--summary] [--prompt]
[--conditions] [--vars] [--value]
config ...
Kconfig symbol determination
positional arguments:
config configuration option to check
args <path to .config> <path to kernel source tree>
optional arguments:
-h, --help show this help message and exit
-c DOTCONFIG, --dotconfig DOTCONFIG
path to the .config to load (default: None)
-s KSRC, --ksrc KSRC path to the kernel source (default: None)
-v verbose (default: False)
--summary Show variable summary (default: False)
--prompt Show variable prompt (default: False)
--conditions Show config option dependencies (default: False)
--vars Show the dependent variables (default: False)
--value Show the config value (default: False)
Example when run from the kernel source directory:
% ARCH=x86 symbol_why.py --dotconfig=.config --ksrc=. BT_CMTP --summary
--conditions
Symbol BT_CMTP
Type : tristate
Value : "n"
User value : (no user value)
Visibility : "n"
Is choice item : false
Is defined : true
Is from env. : false
Is special : false
Prompts:
"CMTP protocol support" if BT_BREDR && ISDN_CAPI (value: "n")
Default values:
(no default values)
Selects:
(no selects)
Reverse (select-related) dependencies:
(no reverse dependencies)
Additional dependencies from enclosing menus and ifs:
NET (value: "y")
Locations: net/bluetooth/cmtp/Kconfig:1
Config 'BT_CMTP' has the following conditionals:
BT_BREDR && ISDN_CAPI (value: "n")
Dependency values are:
BT_BREDR [y] ISDN_CAPI [n]
And the user can now see details on the option, the final value, the
conditionals (dependencies) and what the value of the dependency
config items.
Hence, when an option is dropped for a .config, the information on
how to resolve the issue is provided to the user.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
Bruce Ashfield
svdb
William Bourque
Bruce Ashfield