| Age | Commit message (Collapse) | Author |
|---|
|
qemu in general doesn't define CONFIG_FOO if it's false. This also
helps with the dumb kconfig parser from meson, as source_set considers
any non-empty value as true.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
config-all-devices.mak
When minikconf writes config-devices.mak, it includes all variables including
those from MINIKCONF_ARGS. This causes values from config-host.mak to "stick" to
the ones used in generating config-devices.mak, because config-devices.mak is
included after config-host.mak. Avoid this by omitting assignments coming
from the command line in the output of minikconf.
Reported-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Tested-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The result of this typo would be that "select_foo" would be treated as a "select"
keyword followed by "_foo". Nothing too bad, but easy to fix so let's be clean.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Apart from defconfig (which is a no-op),
allyesconfig/allnoconfig/randcondfig can be implemented simply by ignoring
the RHS of assignments and "default" statements. The RHS is replaced
respectively by "true", "false" or a random value.
However, allyesconfig and randconfig do not quite work, because all the
files for hw/ARCH/Kconfig are sourced and therefore you could end up
enabling some ARM boards in x86 or things like that. This is left for
future work, but I am leaving it in to help debugging minikconf itself.
allnoconfig mode is tied to a new configure option, --without-default-devices.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The Kconfig files were generated mostly with this script:
for i in `grep -ho CONFIG_[A-Z0-9_]* default-configs/* | sort -u`; do
set fnord `git grep -lw $i -- 'hw/*/Makefile.objs' `
shift
if test $# = 1; then
cat >> $(dirname $1)/Kconfig << EOF
config ${i#CONFIG_}
bool
EOF
git add $(dirname $1)/Kconfig
else
echo $i $*
fi
done
sed -i '$d' hw/*/Kconfig
for i in hw/*; do
if test -d $i && ! test -f $i/Kconfig; then
touch $i/Kconfig
git add $i/Kconfig
fi
done
Whenever a symbol is referenced from multiple subdirectories, the
script prints the list of directories that reference the symbol.
These symbols have to be added manually to the Kconfig files.
Kconfig.host and hw/Kconfig were created manually.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Message-Id: <20190123065618.3520-27-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
There are three parts in the semantic analysis:
1) evaluating expressions. This is done as a simple visit
of the Expr nodes.
2) ordering clauses. This is done by constructing a graph of variables.
There is an edge from X to Y if Y depends on X, if X selects Y, or if
X appears in a conditional selection of Y; in other words, if the value
of X can affect the value of Y. Each clause has a "destination" variable
whose value can be affected by the clause, and clauses will be processed
according to a topological sorting of their destination variables.
Defaults are processed after all other clauses with the same destination.
3) deriving the value of the variables. This is done by processing
the clauses in the topological order provided by the previous step.
A "depends on" clause will force a variable to False, a "select" clause
will force a variable to True, an assignment will force a variable
to its RHS. A default will set a variable to its RHS if it has not
been set before. Because all variables have a default, after visiting
all clauses all variables will have been set.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190123065618.3520-25-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add Python classes that represent the Kconfig abstract syntax tree.
The abstract syntax tree is stored as a list of clauses. For example:
config FOO
depends on BAR
select BAZ
is represented as three clauses:
FOO depends on BAR
FOO default n
select BAZ if FOO
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190123065618.3520-24-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This implements a scanner and recursive descent parser for Kconfig-like
configuration files. The only "action" of the parser is for now to
detect undefined variables and process include files.
The main differences between Kconfig and this are:
* only the "bool" type is supported
* variables can only be defined once
* choices are not supported (but they could be added as syntactic
sugar for multiple Boolean values)
* menus and other graphical concepts (prompts, help text) are not
supported
* assignments ("CONFIG_FOO=y", "CONFIG_FOO=n") are parsed as part
of the Kconfig language, not as a separate file.
The idea was originally by Ákos Kovács, but I could not find his
implementation so I had to redo it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190123065618.3520-23-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
