Re: [PATCH v4 5/8] Provide class for easy custom kernel builds

[Alexander Smirnov <asmirnov@ilbers.de>]

On 02/13/2018 10:03 AM, Jan Kiszka wrote:
> On 2018-02-12 19:56, Alexander Smirnov wrote:
>> On 02/11/2018 06:25 PM, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> With this class, it becomes almost trivial to replace the distro kernel
>>> with a custom build. You just need to inherit linux-kernel, specify the
>>> source URI, define via S where the source is unpacked to and provide a
>>> defconfig. To switch to a custom kernel recipe,
>>> PREFERRED_PROVIDER_virtual/kernel has to be adjusted in local.conf or
>>> the distro conf.
>>>
>>> The approach works internally by first running "make deb-pkg" on the
>>> kernel and the repackages the output to make the binary linux-image and
>>> linux-header debs act as replacement of their distro packages. This
>>> results in a suboptimal technical implementation which may eventually be
>>> replaced by an isar-implemented deb-pkg build process. However, this is
>>> not expected to affect the user-visible interface of this class.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>>    meta/classes/linux-kernel.bbclass | 98
>>> +++++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 98 insertions(+)
>>>    create mode 100644 meta/classes/linux-kernel.bbclass
>>>
>>> diff --git a/meta/classes/linux-kernel.bbclass
>>> b/meta/classes/linux-kernel.bbclass
>>> new file mode 100644
>>> index 0000000..5f4df3f
>>> --- /dev/null
>>> +++ b/meta/classes/linux-kernel.bbclass
>>> @@ -0,0 +1,98 @@
>>> +# Custom kernel build
>>> +#
>>> +# This software is a part of ISAR.
>>> +# Copyright (c) Siemens AG, 2018
>>> +#
>>> +# SPDX-License-Identifier: MIT
>>> +
>>> +DESCRIPTION ?= "Custom kernel"
>>> +PROVIDES = "virtual/kernel"
>>> +
>>> +inherit dpkg-base
>>> +
>>> +KERNEL_DEBIAN_DEPENDS ?= "initramfs-tools | linux-initramfs-tool,
>>> kmod, linux-base (>= 4.3~)"
>>> +KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1, gcc"
>>> +KBUILD_DEPENDS ?= "libssl-dev libelf-dev bc"
>>> +
>>> +REPACK_DIR = "${PP}/repack"
>>> +REPACK_LINUX_IMAGE_DIR = "${REPACK_DIR}/linux-image"
>>> +REPACK_LINUX_HEADERS_DIR = "${REPACK_DIR}/linux-headers"
>>> +
>>> +dpkg_runbuild() {
>>> +    E="${@ bb.utils.export_proxies(d)}"
>>> +    sudo -E chroot ${BUILDCHROOT_DIR} sh -c '
>>> +        set -e
>>> +
>>> +        apt-get install -y -o Debug::pkgProblemResolver=yes \
>>> +            --no-install-recommends ${KBUILD_DEPENDS}
>>> +
>>> +        cd ${PP}/${S}
>>> +        cp ../defconfig .config
>>> +        make olddefconfig
>>> +
>>> +        make -j ${@bb.utils.cpu_count() * 2} deb-pkg
>>> +
>>> +        rm -rf ${REPACK_DIR}
>>> +        mkdir -p ${REPACK_DIR}
>>> +        mkdir -p ${REPACK_LINUX_IMAGE_DIR}
>>> +        mkdir -p ${REPACK_LINUX_HEADERS_DIR}
>>> +
>>> +        cd ${PP}
>>> +        tar xzf linux-${PV}_${PV}-1.debian.tar.gz -C ${REPACK_DIR}
>>> +        dpkg-deb -R linux-image-${PV}_${PV}-1_${KERNEL_ARCH}.deb \
>>> +            ${REPACK_LINUX_IMAGE_DIR}
>>> +        dpkg-deb -R linux-headers-${PV}_${PV}-1_${KERNEL_ARCH}.deb \
>>> +            ${REPACK_LINUX_HEADERS_DIR}
>>> +
>>> +        dpkg-gencontrol -crepack/debian/control \
>>> +            -lrepack/debian/changelog \
>>> +            -frepack/debian/files \
>>> +            -plinux-image-${PV} \
>>> +            -P${REPACK_LINUX_IMAGE_DIR} \
>>> +            -DPackage="linux-image-${KERNEL_ARCH}" \
>>> +            -DSection=kernel \
>>> +            -DPriority=required \
>>> +            -DProvides="${PN}" \
>>> +            -DDepends="${KERNEL_DEBIAN_DEPENDS}"
>>> +
>>> +        # Add Debian-like link installation to postinst
>>> +        touch ${REPACK_LINUX_IMAGE_DIR}/lib/modules/${PV}/.fresh-install
>>> +        sed -i ${REPACK_LINUX_IMAGE_DIR}/DEBIAN/postinst \
>>> +            -e "/^set -e$/a\\
>>> +\\
>>> +if [ -f /lib/modules/${PV}/.fresh-install ]; then\\
>>> +    change=install\\
>>> +else\\
>>> +    change=upgrade\\
>>> +fi\\
>>> +linux-update-symlinks \$change ${PV} /boot/vmlinuz-${PV}\\
>>> +rm -f /lib/modules/${PV}/.fresh-install"
>>> +
>>> +        # Add Debian-like link removal to postrm
>>> +        sed -i ${REPACK_LINUX_IMAGE_DIR}/DEBIAN/postrm \
>>> +            -e "/^set -e$/a\\
>>> +\\
>>> +rm -f /lib/modules/${PV}/.fresh-install\\
>>> +\\
>>> +if [ \"\$1\" != upgrade ] && command -v linux-update-symlinks
>>>> /dev/null; then\\
>>> +    linux-update-symlinks remove ${PV}  /boot/vmlinuz-${PV}\\
>>> +fi"
>>> +
>>> +        dpkg-gencontrol -crepack/debian/control \
>>> +            -lrepack/debian/changelog \
>>> +            -frepack/debian/files \
>>> +            -plinux-headers-${PV} \
>>> +            -P${REPACK_LINUX_HEADERS_DIR} \
>>> +            -Vkernel:debarch="${KERNEL_ARCH}" \
>>> +            -DPackage="linux-headers-${KERNEL_ARCH}" \
>>> +            -DSection=kernel \
>>> +            -DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}"
>>> +
>>> +        dpkg-deb -b ${REPACK_LINUX_IMAGE_DIR} \
>>> +            linux-image-${KERNEL_ARCH}_${PV}-1_${KERNEL_ARCH}.deb
>>> +        rm -f linux-image-${PV}_${PV}-1_${KERNEL_ARCH}.deb
>>> +        dpkg-deb -b ${REPACK_LINUX_HEADERS_DIR} \
>>> +            linux-headers-${KERNEL_ARCH}_${PV}-1_${KERNEL_ARCH}.deb
>>> +        rm -f linux-headers-${PV}_${PV}-1_${KERNEL_ARCH}.deb
>>> +    '
>>> +}
>>>
>>
>> What is the benefit of having this script in the class? I see that we
>> have separate files for:
>>
>>   - buildchroot
>>   - kernel modules
>>
>> Why this chroot script should be a part of bitbake class? This makes
>> debugging much more complicated, because I have no possibility to run
>> this script manually from buildchroot (like I could do with build.sh)
> 
> I played with it, and it "just" took 6 exports to set up the interface
> to script-based build. That will likely not be convenient for debugging
> as well (and I never had to call things manually that way, I got all
> information from logs), but I can keep that pattern. Will also mean:
> back to an include, rather than using a class (no big issue).
> 
>>
>> Also formatting style looks nasty here.
> 
> That's not going to change unless you suggest some alternative for the
> sed-based code injection into postinst/postrm.

Just for sure that I understand the issue, why no sed injections? You 
already do this for kernel module by "sedding" control file.

Alex