seL4Config.cmake is responsible for generating a valid
CMAKE_TOOLCHAIN_FILE and setting up platform config options at the start
of the build. The CMAKE_TOOLCHAIN_FILE variable has to be set before the
first cmake `project()` function is processed to take effect.
Previously this file was required to be imported in a CMake script
before the kernel's CMakeLists.txt could be processed. This prevented
the main CMakeLists.txt file from being used without an additional
configuration file:
cmake -G Ninja -C ../configs/ARM_verified.cmake ../
Now it is possible to do:
cmake -G Ninja -DKernelPlatform=imx6 -DKernelARMPlatform=sabre ../
This should make it easier to invoke CMake for building kernel
configurations from other build environments.
Because this file is now imported in the Kernel's CMakeLists.txt
context, there is no longer a requirement to save all the intermediate
settings into the cache and then read them out again.
Signed-off-by: Kent McLeod <kent@kry10.com>
For RISC-V platforms that do not provide machine instructions to count
leading and trailing zeros, this commit includes more efficient library
functions. For verification, we expose the bodies of the functions to
the proofs.
Kernel config options `CLZ_BUILTIN` and `CTZ_BUILTIN` allow selection of
whether compiler builtin functions should be used. These are only
supported on platforms where the builtin compiles to inline assembly. By
default, the options are on for all platforms except RISC-V.
Signed-off-by: Matthew Brecknell <Matthew.Brecknell@data61.csiro.au>
This commit also converts our own copyright headers to directly use
SPDX, but leaves all other copyright header intact, only adding the
SPDX ident. As far as possible this commit also merges multiple
Data61 copyright statements/headers into one for consistency.
This leverages #!/usr/bin/env -S cmake -P to invoke a cmake
configuration file as a script that configures and builds a kernel in
the current directory with the configuration that was invoked. It is a
quick way for producing a kernel.elf or kernel_all_pp.c input file to
verification for a particular config.
Allow projects that use the kernel as a subproject to configure the
kernel in -C scripts.
CMake supports providing a script via -C upon first initialisation of a
build directory. This script is expected to populate the configuration
cache for the rest of the build to depend on. This is how standalone
kernel builds are currently configured. However in buildsystems that add
the kernel as a subproject, it was up to the application to modify
configuration properties before or after the kernel was imported. This
lead to circular dependencies where properties were changed by a module
later in the build, but this then invalidated properties that were set
based on the first property's original value. This lead to running CMake
multiple times in order for settings to reach a stable state.
We now assume that most shared system configuration occurs in initial -C
settings evaluation. seL4Config.cmake is a configuration module that the
kernel exports that allows a configuration script to set kernel platform
and architecture settings in a way that doesn't introduce circular
dependencies.
seL4Config can be imported into other configuration files. This should
make it easier for a full system configuration script to query and
configure kernel configuration values without introducing circular
dependencies on configuration properties.
Instead of processing each platform CMake file during the arch's
config.cmake file, we process all of the platform CMake files first.
This is primarily motivated by wanting to move platform configuration
into a config file that is processed via a -C argument to the initial
build initialisation command.
Now a platform config is responsible for setting the kernel architecture
and it's own platform/arch specific config settings. Where previously a
platform was chosen in an arch specific way via either setting
KernelARMPlatform or KernelX86Sel4Arch or KernelRiscVPlatform, a
platform can now be set by KernelPlatform. In cases where a platform may
further parameterise its configuration it is free to choose its own
config options to query. Platforms that support multiple seL4
architectures should use KernelSel4Arch to query this. Platforms that
provide sub platforms such as exynos5 and subplatforms exynos5250,
exynos5410 and exynos5422 can be selected by specifying
KernelPlatform=exynos5, KernelARMPlatform=exynos5410 for example.
