| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
|
|
|
|
|
| |
The most frustrating part of updating syzbot configs is figuring out
what config options (possibly transivitely) selected the configs we
wanted to stay disabled.
For each "X is present in the final config" message, auto-generate
a small list of enabled config options that may have transitively
"select"ed X.
|
| |
|
|
|
|
|
|
|
| |
It's almost never reasonable to keep on generating configs after some
targets have already failed. We have a lot of different kernels and
regenerating them all takes a very long time.
Having to regenerate everything on each iteration slows down the
development significantly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is the standard way now.
Since our configuration permits multiple parameter value combinations,
explicitly check for the compiler and linker that were to be passed via
CC and LD, and replace that with LLVM=1 if they were clang and ld.lld
correspondingly.
Update syz-kconf to rely on pkg/build's exported functionality for
generating Linux kernel build arguments.
|
| |
|
|
|
|
| |
Currenlty we are getting random flakes in the resulting config
b/c the last section (with all "is not set" configs) is unordered.
This somehow affects olddefconfig and it produces random results.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Baseline configs were meant to be the minimum configs, however, since
they are based on defconfigs, they are still quite big.
To facilitate even smaller baseline configs, let's split the `baseline`
feature in two:
1) `baseline` only disables the addition of extra features on top of
baseline config. It's enabled for `-base.config` files automatically,
but can be also manually set, e.g. if we only want to add debug
configs on top of a defconfig.
2) `base-config` is automatically set for `-base.config` files and can
be used to disable configs in those files.
Regenerate configs.
|
| |
|
|
|
|
|
| |
Allow modules in config if `modules` are specified in main.yml.
Added Cuttlefish instances for android13-5.10, android13-5.15, and
android14-5.15 branches.
|
| | |
|
| |
|
|
| |
Required for ChromeOS update.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Background:
- syz-kconf loads and overlays config fragments to form a final kernel
config. Fragments are loaded top to bottom as defined in the includes
section of main.yml or your downstream syz-kconf config.
- A config fragment loaded later can override kconf options set by an
earlier loaded fragment. However the override keyword can only be used
if an earlier fragment really did set the same option. Otherweise an
error is raised.
- With this in mind it makes sense to load fragments from broadest scope
to most specific e.g. base -> x86_64 -> chromeos, so that chromeos can
override a setting usually enabled on x86_64 machines.
The Problem:
- Before this change shell snippets were executed in order they were
loaded from the fragments.
- This is unfortunate as the broad fragments like x86_64.yml expect to
operate on an existing .config with their shell snippets. Meanwhile
some downstream distros like icebreaker generate their config using
such a shell snippet.
- Hence ordering the fragments like base -> x86_64 -> icebreaker results
in an error about the x86_64 not finding a .config without this
change. Meanwhile ordering icebreaker -> base -> x86_64 works, but
means the icebreaker fragment can't override x86_64 kconf options.
The Solution:
- This change resolves the problem outlined above by reversing the order
shell snippets are executed. Now shell snippets will be executed
starting with the most recently loaded fragment. This way the proposed
fragment order base -> x86_64 -> icebreaker becomes viable.
- Luckily the shell section isn't heavily used, so this change didn't
result in meaningfull final config changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Config option names in .yml files should be specified without the
CONFIG_ prefix (similarly to how they are written in .config files).
Accidentally writing the CONFIG_ prefix leads to non-obvious bugs that
are hard to spot.
Make kconf print a warning about config options with the leading
CONFIG_, e.g.:
Warning: excessive CONFIG_ in CONFIG_IPC_NS at base.yml:76 ?
|
| |
|
|
|
| |
Kernel Makefile uses raw linker in some cases (for version check).
So allow to override it as we do for compiler.
|
| | |
|
| |
|
|
| |
This allows to use compiler dependent on arch and/or from kernel build/source dir.
|
| |
|
|
| |
This will be needed at least for kmsan config which needs a fresh clang.
|
| |
|
|
|
|
|
|
|
|
|
| |
When we appended verbatim blocks we added '\n' for each of them,
(for every config file effectively). Even for empty verbatim blocks.
This worked fine because we had only 1 verbatim block and we do
TrimSpace for the resulting concatenated verbatim block
(so all excessive '\n' were removed). But this does not work for
multiple verbatim blocks because excessive '\n' will be in the middle
and won't be removed by TrimSpace.
Don't add '\n' for empty verbatim blocks.
|
| |
|
|
|
|
| |
Parsing error may depend on the instance config.
For some errors it's hard to understand why it happens
without knowing the instance name.
|
| |
|
|
|
| |
Turns out kernel version is always encoded in the Makefile.
So just read it from there.
|
| |
|
|
|
|
| |
Allow and "_" instance that can list intentionally unused features.
This allows to reuse upstream config bits (e.g. debug.yml)
and avoid "unknown feature" warnings.
|
| |
|
|
|
|
| |
We list a number of configs in fragments intended for non-reduced instances.
However, lots of these configs are enabled by defconfig anyway.
This is not what we want, we want to actually disable them on reduced instances.
|
| |
|
|
|
|
|
|
|
|
| |
Currently it's too easy to misspell a config constraint, e.g.:
config:
- FOO: [arm54]
and it will be silently excluded from all resulting configs.
Check that each constraint is enabled for at least 1 instance.
|
| |
|
|
|
|
|
| |
Support the following syntax:
config:
- CONFIG_WITH_INT_VALUE: [42, arm64]
|
| | |
|
| | |
|
| |
|
|
| |
This will be needed for CMDLINE: common + per-arch + per-kernel.
|
| |
|
|
|
|
| |
Kconfig depends on the target arch.
Add target argument for Kconfig parsing.
Resolve $(SRCARCH) properly (previously we always assumed x86_64).
|
| |
|
|
|
|
| |
We currently detect v5.10-rc1 as v5.9 because we ignore -rc tags.
This makes it impossible to enable configs that were already added for v5.10.
Treat v5.10-rc1 as v5.10 already.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We use strings to identify OS/Arch.
These strings are duplicated throughout the code base massively.
golangci-lint points to possiblity of typos and duplication.
We already had to define these names in pkg/csource
and disable checking for prog package. A future change triggers
such warnings in another package.
Add OS/Arch name consts to sys/targets so that they can be used
to refer to OS/Arch. Use the consts everywhere.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currenty we run oldconfig and set all missing configs to their
default values. Sometimes this enables configs implicitly/unintentionally.
Set all missing configs to "is not set" proactively to prevent
using default values.
Also replace oldconfig with olddefconfig.
I assumed oldconfig sets missing values to "is not set",
but it does not. It does the same as olddefconfig without stdin.
Update #2171
|
| |
|
|
|
|
|
| |
We enabled USB configs everywhere, except for out main KASAN config.
This makes no sense. Enable them in the KASAN config.
Update #2171
|
|
|
syz-kconf generates all Linux kernel configs.
Update #2171
|
