Skip to content

Conversation

@rbilovol
Copy link

These two patches allow cross-compiled LivePatch generation.
They fix two cross-compile scenarios:

  • building LivePatch for another architecture
  • building LivePatch for another distro

This has been tested on OpenEmbedded build system.

This patch introduces new option for kpatch-build
script "--cross-compile" which can be used for
specifying cross-complier prefix.
It allows to build live patches not only on
target system, but also on hosts for a target other
than the one on which the compiler is running

Also removed quotes in exec lines, so it is
possible to pass multy-component strings like
"ccache x86_64-xelinux-linux-" as cross-compiler

Signed-off-by: Ruslan Bilovol <rbilovol@cisco.com>
It is sometimes useful to have ability to override
distro name, for example during cross-compilation
build when livepatch modules will be ran on the
target which differs from host.

This patch adds a new --distro option which
implements all needed functionality

Signed-off-by: Ruslan Bilovol <rbilovol@cisco.com>
@sm00th
Copy link
Contributor

sm00th commented Mar 26, 2018

What is your usecase for the --distro option? $DISTRO in kpatch-build is mostly used for autodetection of source/vmlinux locations which is not useful when you are building for a different target. The only check that should have any effect would be the copy_user_64.o workaround for rhel7.

@rbilovol
Copy link
Author

Currently I use --distro option just to disable existing (and future) distro-specific hacks/tunings when build LivePatches for another distro. In the future, though, we may have OpenEmbedded/Yocto-specific tunings which we want to specify.

@joe-lawrence
Copy link
Contributor

Hi @rbilovol , are you currently cross compiling kpatches and if so, from which arch to which arch? I see where this is PR is coming from by adding the prefix to invoke the other compiler, but I'm not sure if this is enough: What about the ARCH variable in kpatch-build? How would the gcc plugins (see kpatch-build/gcc-plugins directory) interact with cross-compiling? Does this cross-build kmod/patch/kpatch.ko etc.

BTW, this would be a really nice feature to have as I have an s390 cross compiler installed on my machine and it would be handy to test a few builds once we have s390 kpatch support.

@jpoimboe
Copy link
Member

jpoimboe commented Apr 3, 2018

Hi @rbilovol. In addition to @joe-lawrence 's questions...

For --cross-compile, I don't think a new cmdline argument is necessary. Instead I would suggest that the user use an environment variable. In fact, we should probably just use the same variable which is used to cross-compile the kernel: CROSS_COMPILE.

I also don't see the point of --distro, since, as @sm00th mentioned, those mostly just affect the defaults for finding files. Can you be more specific about why it's needed?

@jpoimboe
Copy link
Member

@rbilovol ping?

@rbilovol
Copy link
Author

Hi guys, sorry for late reply
Yes, we can avoid adding --cross-compile option, and use CROSS_COMPILE variable from environment, then pass it as KPATCH_CROSS_COMPILE to kpatch-gcc. With --distro option, things are a little bit different, as there are host-specific hardcoded PATH modification which I'd like to avoid as during Yocto/Openembedded build we have our own predefined set of tools. Also there is RHEL-specifc workaround to arch/x86/lib/copy_user_64.o. So kpatch-build works differently depending on linux distron in case of cross-compilation. We can enable copy_user_64.o workaround as default for any distro to be consistent, as it seems it has no any side-effect.

From user perspective, I don't compile kpatch.ko, I always use livepatch from Linux Kernel
Currently this was tested on x86-64 cross-compiling for another x86-64 distro, and was not tested on PPC64. I'd like to test it on x86-64 -> ARM64 cross-compilation though

So I'll update the patches addressing current comments, at least for CROSS_COMPILE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants