linux/poky.git/meta/classes/kernel.bbclass, branch 2.5_M1

kernel: Add support for multiple kernel packages

2018-01-02T17:24:37+00:00

Some distros may want to provide alternate kernel "flavors" via feeds or within bootable images. For example, readily available builds which provide certain diagnostic features can enable developers and testers to more quickly resolve issues by avoiding lengthy kernel builds. This change allows for building multiple flavors of the kernel and module packages by templatizing kernel package names via a new KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old name of "kernel", but can be overridden by certain recipes providing alternate kernel flavors. To maintain compatibility, recipes providing alternate kernel flavors cannot be the "preferred provider" for virtual/kernel. This is because OE puts the preferred provider's build and source at "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build in the old location and may be preferred provider -- while recipes using all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't provide "virtual/kernel". Testing: 1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"` to local.conf so that linux-yocto-tiny may build alongside the main kernel (linux-yocto). 2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors. 3. Verified image and modules IPKs exist for both: tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny 4. Verified linux-yocto is the "preferred provider", and was built in shared directory: tmp-glibc/work-shared/qemux86/kernel-* 5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base = "tiny-linux"` to local.conf to install both kernel flavors in core-image-base. 6. `bitbake core-image-base` to build an image. 7. Verified image contains two bzImage's under /boot/, with "yocto-standard" (linux-yocto recipe) selected to boot via symlink. Discussion threads: http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122 http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130 [YOCTO #11363] (From OE-Core rev: 6c8c899849d101fd1b86aad0b8eed05c7c785924) Signed-off-by: Ioan-Adrian Ratiu Signed-off-by: Gratian Crisan Signed-off-by: Haris Okanovic Coauthored-by: Gratian Crisan Coauthored-by: Haris Okanovic Coauthored-by: Josh Hernstrom Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: Fix do_sizecheck behaviour

2018-01-02T17:24:37+00:00

During the introduction of support for multiple kernel image types in 849b67b2e4820564b5e5c9bd4bb293c44351c5f3, do_sizecheck was changed to only warn if any kernel was bigger than ${KERNEL_IMAGE_MAXSIZE}. (Well, it tried to warn - it turns out that there's no function called "warn", it should be "bbwarn".) The previous behaviour had been to fail the build if the single kernel image did not fit. It seems possible that people might be generating both compressed and uncompressed kernels and only really care whether the compressed one fits. This means that we shouldn't just always fail if any of the images are too large. So, let's warn (correctly this time) on every image that is too large, but only ultimately fail if no image will fit. The build will also fail if ${KERNEL_IMAGETYPES} is empty, but I hope that no-one needs to do that. While we're here correct a typo in the KERNEL_IMAGE_MAXSIZE validity check. (From OE-Core rev: 59f1ee104d1a6c04b0690b7c8ce481449da174d6) Signed-off-by: Mike Crowe Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: Add cleandirs for do_shared_workdir

2017-12-10T22:45:18+00:00

We add the kernel-build-artifacts to the cleandirs list to ensure that there are no remaining artificats in the kernel-build-artifacts directory which is STAGING_KERNEL_BUILDDIR. Without this change multiple System.map files are visiable in the STAGING_KERNEL_BUILDDIR, which could cause problems for some tools. [YOCTO #11880] (From OE-Core rev: d52a65d3d8512eeb5081d9fb5f18805428358241) Signed-off-by: Saul Wold Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: build host programs with native sysroots

2017-09-21T08:24:25+00:00

Allow to search header files and libs from native sysroots. For example, an expanded BUILD_CFLAGS includes: '-isystem/builddir/to/linux-yocto/recipe-sysroot-native/usr/include' And an expanded BUILD_LDFLAGS includes: '-L/builddir/to/linux-yocto/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/builddir/to/linux-yocto/recipe-sysroot-native/usr/lib -Wl,-rpath,/builddir/to/linux-yocto/recipe-sysroot-native/usr/lib' (From OE-Core rev: 37f20f2f7bdc8b964736c09371cd8f2342e4d5cb) Signed-off-by: Wenzong Fan Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel: Move Device Tree support to kernel.bbclass

2017-09-13T21:07:42+00:00

The Device Tree is commonly used but it is still kept as a .inc file instead of a proper class. Instead now we move the Device Tree code to a kernel-devicetree class and automatically enable it when the KERNEL_DEVICETREE variable is set. To avoid breakage in existing layers, we kept a linux-dtb.inc file which raises a warning telling the user about the change so in next release this can be removed. (From OE-Core rev: 03a00be7f2062aefef0e51ef20a4c9737f6685e7) Signed-off-by: Otavio Salvador Signed-off-by: Richard Purdie

kernel: Stop using update-alternatives

2017-09-11T16:30:28+00:00

The update-alternatives where using relative links so not being really in use since December 2016 (see OE-Core:c7bc46b9 "kernel: Fix symlinks") so instead we now generate the relative symlinks during the do_install task and drop the update-alternatives use at all. Acked-by: Saul Wold (From OE-Core rev: 10a1b293191268e6792ac8e27bd6427f1974c7ce) Signed-off-by: Otavio Salvador Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: external toolchain fix

2017-08-23T11:06:51+00:00

Refactor get_cc_option so it is simpler and also does not fail when using external toolchain. (From OE-Core rev: d4564ee59df907d1e01a3610ac88a35f9a78c1ce) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

kernel.bbclass: improve reproducibility

2017-08-15T23:03:15+00:00

Several tweaks to improve reproducibility: 1. If BUILD_REPRODUCIBLE_BINARIES == 1, set KBUILD_BUILD_TIMESTAMP to a reproducible value. This is either a non-zero SOURCE_DATE_EPOCH, or the value obtained from top entry of GIT repo, or (if there is no GIT repo) fallback to REPRODUCIBLE_TIMESTAMP_ROOTFS as the last resort. Also export KCONFIG_NOTIMESTAMP=1. 2. When compressing vmlinux.gz, use gzip "-n" option 3. Kernel and kernel modules contain hard coded paths referencing the host build system. This is usually because the source code contains __FILE__ at some place. This prevents binary reproducibility. However, some compilers allow remapping of the __FILE__ value. If we detect the compiler is capable of doing this, we replace the source path $(S) part of __FILE__ by a string "/kernel-source". For example: /data/master/build/tmp/work-shared/qemux86/kernel-source/drivers/media/v4l2-core/videobuf2-core.c will be replaced by a reproducible value: /kernel-source/drivers/media/v4l2-core/videobuf2-core.c. (From OE-Core rev: 012a70da7ae0617740cd0cf807d01c3cd912c823) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

kernel.bbclass: set CVE_PRODUCT to linux_kernel if not set by recipe

2017-07-24T08:13:31+00:00

It is used by NVD database CVE's like: https://nvd.nist.gov/vuln/detail/CVE-2017-7273 Setting this in kernel.bbclass fixes CVE reporting for all users of the class. (From OE-Core rev: 2e3d325440a50265c73f7d2e782530a02458bc33) Signed-off-by: Mikko Rapeli Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: fix KERNEL_IMAGETYPE(S) for Image.gz

2017-06-05T08:19:51+00:00

KERNEL_IMAGETYPES lists all the kernel images that we want to build. in cb17b6c2a7 (kernel.bbclass: support kernel image type of vmlinux.gz), some logic was added to support vmlinux.gz which is not a target built by kernel makefiles (only vmlinux). It is clear that the goal of this logic is only to support vmlinux.gz and not others compressed format (such as Image.gz) which are valid target for kernel makefiles. For Image.gz we should rely on the kernel makefiles and not do the compression in kernel class. This patch updates the logic used to filter out non supported kernel target from KERNEL_IMAGETYPES, and make vmlinux.gz a 'special case', instead of *.gz. If more special cases are needed in the future, we could add them in a similar way. This patch should be a no-op for anyone using vmlinux or vmlinux.gz, and on top of that it is fixing the build for Image.gz which was not working until now. (From OE-Core rev: cfc0c897656fe67e81a6a5dcd936dff785529f41) Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie