New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a target for building kernel with buildx #3792
Conversation
Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
This surpringly saves a lot of time: M1: from 340 to 90 seconds Intel: from 527 to 222 seconds (2 cores 4 threads) Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
buildx can use remote builders and automatically generate the multiarch manifest. A properly configured builder is required : First create docker context for the remote builders : $ docker context create node-<arch> --docker "host=ssh://<user>@<host>" Then create a buildx configuration using the remote builders: $ docker buildx create --name kernel_builder --platform linux/amd64 $ docker buildx create --name kernel_builder --node node-arm64 --platform linux/arm64 --append $ docker buildx use kernel_builder $ docker buildx ls Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
How does this align with the work done in |
@rn particularly will have to comment on this. |
I used to build kernels directly using make, and had a hardtime with multiarch images, and buildx just fitted so well here. Maybe I was just doing it wrong. |
Not necessarily. At the moment, we still build kernels mostly directly, not via |
kernel/Makefile
Outdated
--build-arg DEBUG=$(4) \ | ||
--build-arg BUILD_IMAGE=$(IMAGE_BUILDER) \ | ||
$(LABELS) \ | ||
--no-cache -t $(ORG)/$(IMAGE):$(1)$(3)$(4)-$(TAG)$(SUFFIX) . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the suffix is not needed in the manifest image name
Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
To update configuration for 5.10 kernels use : make -C kernel KERNEL_VERSIONS=5.10.104 kconfigx Signed-off-by: Frédéric Dalleau <frederic.dalleau@docker.com>
It would be nice to build kernels with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think building kernels with linuxkit pkg build
is still a good end goal to aim for. As far as I can see this PR is a small incremental improvement to the current process: builds are faster and support remote builders. I don't think this blocks or conflicts with any work on linuxkit pkg build
and gives us some short-term benefits.
I think we should take this and still work on improving linuxkit pkg build
.
# Apply patches to all kernels and move config files into place | ||
RUN <<EOF | ||
set -e | ||
for VERSION in ${KERNEL_VERSIONS}; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this actually only accepts one version in here because same arg is also used in COPY
.
patch \ | ||
xz | ||
|
||
COPY / / |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be after source download/extraction iiuc.
To minimize cache misses you could only pull in the config-x/patches
file that you actually need. Or because you only need the context files for a single RUN
you could just mount in the files with --mount=target=.
for that step and avoid copy completely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The makefile sets --no-cache
actually...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why? It is also weird that it is doing a pull based on name, instead of for example doing a --cache-from
from the previous image that would verify that cache is up-to-date and only pull if there is an actual cache match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why?
I think that's just been a LinuxKit policy since the early days, see e.g. edeaf1c.
It is also weird that it is doing a pull based on name, instead of for example doing a
--cache-from
from the previous image that would verify that cache is up-to-date and only pull if there is an actual cache match.
If you are referring to docker pull $tag || docker build --tag $tag
pattern, I am pretty sure the idea is to avoid building if a tag is already present. It's not about cache, is about whether the unique image version was already released or still needs building and releasing.
ARG KERNEL_VERSIONS | ||
ARG TARGETARCH | ||
WORKDIR / | ||
COPY --from=kernel-build /linux-${KERNEL_VERSIONS}/.config config-${KERNEL_VERSIONS}-$TARGETARCH |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because $TARGETARCH
is not the same format and needs a special rename in a makefile, a better pattern in there could be to do something like cp .config /out/config-real-name
in the RUN
step and then in here just do COPY --from=kernel-build /out /
- What I did
this pr contains various improvements
- How I did it
Add a new target in the makefile
- How to verify it
ORG=yourorg IMAGE=yourimage PLATFORMS=linux/arm64,linux/amd64 make -C kernel buildx_5.10.x
- Description for the changelog
kernel: Add a target for building kernel with buildx
- A picture of a cute animal (not mandatory but encouraged)