From: "Koch, Stefan" <stefan-koch@siemens.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
"Kiszka, Jan" <jan.kiszka@siemens.com>
Cc: "Sudler, Simon" <simon.sudler@siemens.com>,
"Storm, Christian" <christian.storm@siemens.com>,
"Adler, Michael" <michael.adler@siemens.com>
Subject: Re: [PATCH 0/3] linux-custom: Split up binaries from kernel headers to kbuild packages
Date: Wed, 9 Nov 2022 15:06:54 +0000 [thread overview]
Message-ID: <dcaf95294dbb8282cb47e6382e859b5287b5be8e.camel@siemens.com> (raw)
In-Reply-To: <bf3b3053-2493-64d7-d121-bc8866ed33bd@siemens.com>
On Wed, 2022-11-09 at 12:50 +0100, Jan Kiszka wrote:
> On 09.11.22 11:32, Koch, Stefan (DI PA DCP R&D 3) wrote:
> > Hi
> >
> > This patchset is a set of three patches:
> > - Support overwriting configured schroot dir
> > - Split up binaries from kernel headers to kbuild packages
> > - Update custom_kernel docs for split up of kernel scripts and
> > tools
> >
> > The main use-case was to swap out the binaries
> > from the kernel headers package.
> > They will be swapped out into host and target
> > specific kernel kbuild packages.
> >
> > The main development goals were these:
> >
> > 1. Solve already known isar custom kernel
> > limitations from doc/custom_kernel.inc
> > - kernel headers package does not support both native
> > and cross compilation of kernel modules when cross built
>
> Right, that requires building packages for multiple architectures.
Important feature... Maybe it should be added to the TODO list in the
docs?
> This
> is the feature we need, and it has nothing to do with the kernel
> packages per se.
The way that I assume debian will do building the kernel is that they
use a generic debian defconfig for each architecture.
E. g. linux-config-5.10/config.amd64_none_amd64.xz, linux-config-
5.10/config.arm64_none_arm64.xz
ISAR builds are often using specific defconfigs honored by ISAR's
linux-custom for the target build.
Debian specific architecture builds (e. g. host and target, maybe with
sbuild) for one target device, using target specific stripped-down
defconfigs, may not working properly. The kernel build for a foreign
architecture (e. g. host) may fail because of an incompatible
defconfig.
Debian provide a generic very similar defconfig for different
architectures, and they build the linux-image, linux-headers and linux-
kbuild for each architecture:
- So I assume the linux-kbuild:amd64 was build with linux-config-
5.10/config.amd64_none_amd64.xz
- So I assume the linux-kbuild:arm64 was build with linux-config-
5.10/config.arm64_none_arm64.xz
The debian generic defconfig may differ in some arch specific points
but you can use the linux-kbuild:amd64 for a cross-build of linux-
image:arm64 because the resulting scripts and tools are from the
identical set. So mixing linux-headers with different archictecture
specific builds from linux-kbuild should work since the defconfigs have
a "shared base" (e. g. both define CONFIG_HAVE_C_RECORDMCOUNT thats
needed for recordmcount utility as example).
> Jan
>
> >
> > 2. Honor recommendations for future from doc/custom_kernel.inc
> > - Generate kernel headers packages for both host and target
> > when using cross build
> >
> > 3. Add extensions known from debian kernel packages structure
> > - Generate a kernel headers package without binaries
> > - Create specific kernel kbuild packages that
> > will ship the "scripts" and "tools" binaries
> > - Use symlinks to point to the "scripts" and "tools" binaries
>
> Keep in mind that we intend to remain compatible with the layout of
> Debian. Self-built kernels should remain drop-in replacements of the
> Debian kernel packages. And that is true for development packages as
> well.
>
> So, are your changes working against that, or are they improving
> existing incompatibility with the debian packages?
The approach from this patchset does build the kernel in the known ISAR
specific way. Debian itself patches the kernel Makefiles to modularize
the kernel build what ISAR doesn't do. With this patch the packages
linux-kbuild and linux-kbuild-cross are the only new packages that the
ISAR build will provide. That means ISAR will provide then linux-
headers, linux-image and linux-kbuild. They match on the target with
the package name of the respective debian packages. So the existing
drop-in should not be affected.
In short this patch brings the ISAR linux-custom mechanism a bit nearer
to the debian package structure. Since linux-headers behaves then more
like the original debian linux-heades to ship the binaries within a
separate package -> linux-kbuild.
The trick is to build only the scripts and tools with schroot-target
(QEMU) in a non-cross way. Since the kernel does not support building
the scripts and tools for target architecture when do a cross build
without patching the kernel Makefiles. I think that patch was never
merged into the kernel:
https://patchwork.kernel.org/project/linux-kbuild/patch/1376046432-12588-1-git-send-email-broonie@kernel.org/
--
Stefan Koch
Siemens AG
www.siemens.com
next prev parent reply other threads:[~2022-11-09 15:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 10:32 Koch, Stefan
2022-11-09 10:32 ` [PATCH 1/3] sbuild: Support overwriting configured schroot dir Koch, Stefan
2022-11-09 10:32 ` [PATCH 2/3] linux-custom: Split up binaries from kernel headers to kbuild packages Koch, Stefan
2022-11-11 5:34 ` Uladzimir Bely
2022-11-11 9:03 ` Koch, Stefan
2022-11-11 10:50 ` Uladzimir Bely
2022-11-09 10:32 ` [PATCH 3/3] docs: Update custom_kernel docs for split up of kernel scripts and tools Koch, Stefan
2022-11-09 11:50 ` [PATCH 0/3] linux-custom: Split up binaries from kernel headers to kbuild packages Jan Kiszka
2022-11-09 15:06 ` Koch, Stefan [this message]
2022-11-09 16:00 ` Jan Kiszka
2022-11-10 17:49 ` Koch, Stefan
2022-11-10 18:33 ` Jan Kiszka
2022-11-10 18:36 ` Jan Kiszka
2022-11-11 9:47 ` Koch, Stefan
2022-11-15 13:44 ` Uladzimir Bely
2022-11-15 17:23 ` Jan Kiszka
2022-11-18 17:11 ` Koch, Stefan
2022-12-20 16:57 ` Koch, Stefan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dcaf95294dbb8282cb47e6382e859b5287b5be8e.camel@siemens.com \
--to=stefan-koch@siemens.com \
--cc=christian.storm@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
--cc=michael.adler@siemens.com \
--cc=simon.sudler@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox