Difference between revisions of "Kernel build bundle"

From eLinux.org
Jump to: navigation, search
(initialize page, and add details about bootlin's 'custom test tool' project)
 
(tools that pass data around)
Line 44: Line 44:
  
 
== tools that pass data around ==
 
== tools that pass data around ==
 +
=== bootline 'custom test tools' ===
 
Bootline has a tool called "custom_tests_tool" that can send the materials for
 
Bootline has a tool called "custom_tests_tool" that can send the materials for
 
kernelci job to a server:
 
kernelci job to a server:

Revision as of 09:36, 21 October 2021

This page describes a standard proposal for a "kernel build bundle".

This is used to describe the build artifacts from a kernel build, that can be referenced and passed to other tools - mainly a provisioning tool, to install a kernel into a test system.

This is not to be confused with boot standards, although those are related.

It is anticipated that a kernel build system will produce a kernel build bundle (or a metadata file that references the kernel build artifacts), and that a test framework might use this to actually provision a system.

pre-existing work and standards

kernel build systems

kernel build system

  • Linux kernel kbuild system (Makefiles and kbuild)

kernelci

The kernelci system builds lots of kernels from mainline trees, with lots of different configurations.

Here is an example output manifest from one build: https://storage.kernelci.org/broonie-regulator/for-next/v5.15-rc1-lava-bisection-9108-pass/arm64/defconfig/gcc-8/artifacts.json

This has a description of information for this online directory: https://storage.kernelci.org/broonie-regulator/for-next/v5.15-rc1-lava-bisection-9108-pass/arm64/defconfig/gcc-8

which has sub-directories: config, dtbs, kernel, and logs

It also has a modules.tar.xz file in the top directory.

tuxmake

Tuxmake is a tool to write

kernel installation systems

There are multiple ways of installing a kernel so that it will boot on a board. Some of these installating methods are persistent (e.g. installed to a filesystem on the device, or a partition on the device), and some are ephemeral. Some examples of this later category are placing the kernel in a tftp directory on a host, or transferring a kernel into ram and executing it using adb.

  • tftp boot
  • etherboot
  • /boot directory on filesystem on device (used by grub)
  • in it's own flash partition
  • in it's own disk partition

tools that pass data around

bootline 'custom test tools'

Bootline has a tool called "custom_tests_tool" that can send the materials for kernelci job to a server:

See this tool: https://github.com/bootlin/custom_tests_tool/blob/master/ctt.py

Some notes:

  • CTTLauncher instance creates an 'artifacts' map, which has:
    • kernel
    • dtb
    • modules
    • rootfs

For any files mentioned in the _cfg, the launch() method can send the file to the REMOTE_ROOT, and change the reference to be local-relative (prepended with 'file://'), before submitting the job.