-
Notifications
You must be signed in to change notification settings - Fork 435
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 support for building under x86_64 User-Mode-Linux (UML) #766
Conversation
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.
Maybe we can also have a CI job for UML?
LGTM too, with the
Indeed. I can do it in another PR. |
The kernel iomem functions are not available on all architectures, in all configurations, so hide the rust bindings behind CONFIG_HAS_IOMEM. This is required for rust to work under UML. Signed-off-by: David Gow <davidgow@google.com>
IRQ domains are not supported under all architectures, so hide the Domain struct (and its implementation) behind CONFIG_IRQ_DOMAIN. This is required for CONFIG_RUST to build and run under UML. Signed-off-by: David Gow <davidgow@google.com>
CONFIG_RUST currently supports x86_64, but does not support it under UML. Adding support is trivial: - Add CONFIG_HAVE_RUST to UML if X86_64 is set. - Have generate_rust_target check for CONFIG_X86_64, which is present under UML, rather than CONFIG_X86, which isn't. Signed-off-by: David Gow <davidgow@google.com>
Fixed the Tested KUnit against arm64, and against UML+IOMEM, and it worked fine:
It'd be great to have a CI job for UML — it'd probably need to be quite different from the existing qemu-based jobs, though (but you could possibly reuse some x86 userspace / initrd stuff). The other option (which I could try hacking together) is to have separate KUnit CI jobs, which could piggy-back on the kunit_tool configs (and potentially run non-rust-specific tests as well, if that were useful). |
Thanks a lot David!
Yeah, it would probably have to be different.
Do you mean having CI jobs that directly run |
|
FYI: I looked briefly into CI with kunit_tool, and it looks like UML doesn't run nicely on GitHub actions, at least out-of-the-box. UML requires /dev/shm to not be marked
Other architectures (at least x86_64 and arm64), under qemu, can be made to work, though. |
User-Mode-Linux is a Linux architecture (
ARCH=um
) which builds the kernel as a normal user-mode binary. It's used, amonst other things, as the default architecture for KUnit tests, and acts as a very fast, lightweight platform for running and testing kernel code.Since Rust-for-Linux already supports x86-64, it's relatively simple to add support for x86-64 UML. Most of the changes are simply excluding code whose dependencies are not met (
CONFIG_IOMEM
andCONFIG_IRQ_DOMAIN
are not set on default UML configs). In addition,CONFIG_HAVE_RUST
is set for X86_64 UML, andgenerate_rust_target
is modified to check forCONFIG_X86_64
instead ofCONFIG_X86
.With these changes, a UML kernel with
CONFIG_RUST=y
builds and runs successfully, and the KUnit tooling can run Rust-based tests as follows:Signed-off-by: David Gow davidgow@google.com