search

ClangBuiltLinux / continuous-integration

Continuous integration of latest Linux kernel with daily build of Clang & LLVM tools
https://travis-ci.com/ClangBuiltLinux/continuous-integration
Apache License 2.0
44 stars 18 forks source link

add support for testing kernel modules #218

Open samitolvanen opened 4 years ago

samitolvanen commented 4 years ago

When working on LTO, I used to frequently run into issues with kernel modules. It would be great if the continuous integration scripts could test that module loading works.

nathanchance commented 4 years ago

I definitely think this would be nice to do. Two immediate issues:

  1. We currently build no modules; that’s easy to fix and I am pretty sure that there is a test module we can build to see if it loads.

  2. Not entirely sure how to reconcile getting the module within QEMU... We in theory could build an initramfs from scratch but that would require an overhaul of our current setup. I’ll have to look more into it.

nickdesaulniers commented 4 years ago

I think we could make it so it's possible to add a new target that doesn't try to boot anything in QEMU. We'll need this for ARCH=hexagon on as they don't yet have a QEMU port.

Then we can add make <whatever builds just modules> as a target for various arch's.

To load them in QEMU, we'd have to rebuild the initramfs on the fly after a kernel build, then boot the result.

We're definitely limited on build time, but I can probably get some resources to improve that.

nathanchance commented 4 years ago

I think we could make it so it's possible to add a new target that doesn't try to boot anything in QEMU. We'll need this for ARCH=hexagon on as they don't yet have a QEMU port.

That should be easy; I can work on that tonight or tomorrow morning.

Then we can add make <whatever builds just modules> as a target for various arch's.

I think modules is the target for that. I can run some targets for Travis to see what that adds in terms of build time. arm64 will probably suffer the most because configs are added for the various architecture drivers every release to the defconfig.

To load them in QEMU, we'd have to rebuild the initramfs on the fly after a kernel build, then boot the result.

We're definitely limited on build time, but I can probably get some resources to improve that.

Yeah I don’t think this is hard from what I have seen? I think we can concatenate initrds so that we have all of the rootfs files + the modules all in one. We’d probably need to refactor most architectures to move from the -drive + -append root= to -initrd if we wanted to do this for everything.

It would be nice to be able to test LTO but we will never be to test that with Travis :/

nickdesaulniers commented 4 years ago

Unless we get ThinLTO working. Shhh :secret:

samitolvanen commented 4 years ago

I think we can concatenate initrds so that we have all of the rootfs files + the modules all in one.

Sure, sounds like that would work. For my local use, I just hacked together a script that builds a separate ext4 image from the output of make modules_install. I then mount it to /lib/modules in the init script, which allows me to use modprobe. Since it's a separate file system, there's no need to touch the rootfs after the initial set-up.

nathanchance commented 4 years ago

That will probably be the cleanest method. I will add it to the laundry list of items I have to look at.