Repository navigation
Initial Rust support - #4
Conversation
Currently we have several lines of work:
- Integrating with the kernel tree and build system (Nick's & mine,
both uploaded as branches, based on `rustc`; and another one I have
been working on, based on `cargo`).
- Bindings and the first bits of functionality (Alex's & Geoffrey's,
based on `cargo`).
This patch effectively merges the work we have been doing and
integrates it in the latest mainline kernel tree.
This does *not* mean anything needs to stay as-is, but this gives us
a working, common base to work and experiment upon. Hopefully, it will
also attract external people to join!
As a summary, I added:
- `cargo` integration with the kernel `Makefile`s:
+ Virtual `cargo` workspace to have a single lock file and to share
deps between `cargo` jobs.
+ Picks the same optimization level as configured for C.
+ Verbose output on `V=1`.
+ A `cargoclean` target to clean all the Rust-related artifacts.
- Initial support for built-in modules (i.e. `Y` as well as `M`):
+ It is a hack, we need to implement a few things (see the `TODO`s),
but it is enough to start playing with things that depend on `MODULE`.
+ Passes `--cfg module` to built-in modules to be able to compile
conditionally inside Rust.
+ Increased `KSYM_NAME_LEN` length to avoid warnings due to Rust
long mangled symbols.
- Rust infrastructure in a new top level folder `rust/`:
+ A `kernel` package which contains the sources from Alex &
Geoffrey's work plus some changes:
* Adapted `build.rs`.
* Removed the `THIS_MODULE` emulation until it is implemented.
* Removed `Makefile` logic and the code that `cfg`-depended
on kernel version (no need in mainline).
* Moved the helpers to be triggered via normal compilation,
renamed them under `rust_*` and exported via
`EXPORT_SYMBOL` instead.
* Added a prelude.
+ A `shlex` package which serves as an example of an "inline"
dependency (i.e. package checked out copy to avoid the network)
- The example driver was setup at `drivers/char/rust_example/`.
- Misc
+ The beginning of `Documentation/rust/` with a quick start guide.
+ `MAINTAINERS` entry.
+ SPDXs for all files.
Other notes that aren't in `TODO`s:
- We could minimize the network requirements (use `bindgen` binary, use more
inline dependencies...), but it is not clear it would be a good idea for
the moment due to `core`/`alloc`/`compiler-builtins`.
- The intention of `rust/` is to have a place to put extra dependencies
and split the `kernel` package into several in the future if it grows.
It could resemble the usual kernel tree structure.
- With several drivers being built-in, `cargo` recompiles `kernel`
and triggers duplicate symbol errors when merging thin archives.
We need to make it only compile `kernel` once.
- When the above works, then `make`'s `-j` calling concurrent `cargo`s
(e.g. several drivers at the same time) should be OK, I think.
According to rust-lang/cargo#2486 it shouldn't
miscompile anything, but if they start locking on each other
we will have make jobs waiting that could have been doing something else.
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
|
commented
Sep 4, 2020
|
I'm not worried about credit at all. I'm so excited to see this moving forward! |
commented
Sep 4, 2020
Yeah, I could have put an initial commit with just those files to make it show easier on GitHub's interface. Let me paste the manual diff here instead.
I don't think anybody understands it... ;) Later on we can ask Masahiro to give us a hand (e.g. to remove the hack I put there to make the distinction between built-in and module).
You're welcome! And thanks for taking a look so quickly :-) |
commented
Sep 5, 2020
|
@alex @geofft The manual diff between the original files and the new ones (minus the repetitive SPDX ones): |
commented
Sep 5, 2020
|
|
commented
Sep 5, 2020
|
And the driver: |
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
commented
Sep 6, 2020
|
This is awesome! I'm going to try to split this out into patches mostly so it's easier for me to review and also because I suspect it'll be better for submission. There might also be some changes we can "upstream" into linux-kernel-module-rust. I had the Kbuild stuff on my mind because of fishinabarrel/linux-kernel-module-rust#266 - do your Kbudild rulesx make .cmd files for us? If so, I might try to roll this approach back into our out-of-tree Makefiles.... Agree re credit, I assume it'll be easy to stick some Co-authored-by lines or whatever, I don't really have a strong opinion about whose name is on it :) |
commented
Sep 6, 2020
|
You'll probably want to cherry-pick fishinabarrel/linux-kernel-module-rust@abc9791 which further reduces the need for nightly features. |
Thanks!
Please note that this repo/branch/commits is only meant for development within GitHub -- later I'll have to squash everything on my side and prepare the proper PR anyway (see #1). So all these dev-commits/messages/merges will go away.
Not much (I intentionally modified as few things as possible in your original files). In particular:
Things that I think you could pick, however, are:
I should have probably left the prelude and SPDX changes for another PR to make it even easier to diff; I wasn't consistent on the strategy there.
What I did is teach kbuild (in a hacky way at some points) how to handle our Rust stuff in a way that adding new Rust modules looks like any other C module and as easy to use as possible, i.e. you only need to write:
Yeah, exactly. |
commented
Sep 7, 2020
|
FWIW, I managed to emulate the #![feature(global_asm)]
global_asm!(
r#".section ".initcall6.init", "a"
__initcall_foo6:
.long foo - .
.previous
"#
);
#[no_mangle]
fn foo() -> i32 {
4
}Converting to a macro that's parameterized on the function name is left as an exercise to the reader :-) |
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
commented
Sep 8, 2020
|
I am starting to wonder whether trying to emulate all the C module support is too much duplication. Perhaps we should generate and compile a C file for each defined Rust module on the fly (without the module writer having to write anything different). Anyway, for the moment I added support to do conditional compilation on the kernel configuration variables (which is anyway good to have!) and used that to fully emulate the macro. That frees us from the |
commented
Sep 12, 2020
|
It has been a week so I am merging this so that we can start sending PRs etc. |
commented
Sep 14, 2020
|
Sorry, guys, I'm slammed at work. Hopefully I can help out more in the future; just excessively busy right now... :( |
commented
Sep 16, 2020
|
Is cargo pulling stuff from the network? Is there a way to make this work with only local crates, i.e. installed by the distro or pre-installed by the user prior to attempting to build the kernel? |
commented
Sep 17, 2020
No worries!
Yeah, it does. For the moment, it is downloading them, although the versions are locked (i.e. no surprise updates, which means no unknown/arbitrary code downloaded when running
To recap the situation of the dependencies for everyone: we can make it work with local code (the
Another topic is avoiding the connections to crates.io and github.com. For that, we could propose to host mirrors at kernel.org. |
|
For crate dependencies, we should vendor those into the kernel tree under a specific path, and then configure that path as a directory source, along with passing the appropriate cargo options to never touch the network. For bindgen/cbindgen, I'm wondering if we can get distributions to package it, and then just expect people to have it installed like cargo and rustc. |
commented
Sep 17, 2020
via email
|
… On Thu, Sep 17, 2020 at 10:17 AM Josh Triplett ***@***.***> wrote:
For crate dependencies, we should vendor those into the kernel tree under
a specific path, and then configure that path as a directory registry,
along with passing the appropriate cargo options to never touch the network.
For bindgen/cbindgen, I'm wondering if we can get distributions to package
it, and then just expect people to have it installed like cargo and rustc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBHXHEW7TYMV6OQUQ53SGIK7PANCNFSM4QZPGBCQ>
.
--
All that is necessary for evil to succeed is for good people to do nothing.
|
Currently we have several lines of work:
rustc; and another one I have been working on, based oncargo).cargo).This patch effectively merges the work we have been doing and integrates it in the latest mainline kernel tree.
This does not mean anything needs to stay as-is, but this gives us a working, common base to work and experiment upon. Hopefully, it will also attract external people to join!
As a summary, I added:
cargointegration with the kernelMakefiles:cargoworkspace to have a single lock file and to share deps betweencargojobs.V=1.cargocleantarget to clean all the Rust-related artifacts.Initial support for built-in modules (i.e.
Yas well asM):TODOs), but it is enough to start playing with things that depend onMODULE.--cfg moduleto built-in modules to be able to compile conditionally inside Rust.KSYM_NAME_LENlength to avoid warnings due to Rust long mangled symbols.Rust infrastructure in a new top level folder
rust/:kernelpackage which contains the sources from Alex & Geoffrey's work plus some changes:build.rs.THIS_MODULEemulation until it is implemented.Makefilelogic and the code thatcfg-depended on kernel version (no need in mainline).rust_*and exported viaEXPORT_SYMBOLinstead.shlexpackage which serves as an example of an "inline" dependency (i.e. package checked out copy to avoid the network)The example driver was setup at
drivers/char/rust_example/.Misc
Documentation/rust/with a quick start guide.MAINTAINERSentry.Other notes that aren't in
TODOs:We could minimize the network requirements (use
bindgenbinary, use more inline dependencies...), but it is not clear it would be a good idea for the moment due tocore/alloc/compiler-builtins.The intention of
rust/is to have a place to put extra dependencies and split thekernelpackage into several in the future if it grows. It could resemble the usual kernel tree structure.With several drivers being built-in,
cargorecompileskerneland triggers duplicate symbol errors when merging thin archives. We need to make it only compilekernelonce.When the above works, then
make's-jcalling concurrentcargos (e.g. several drivers at the same time) should be OK, I think. According to Fix running Cargo concurrently rust-lang/cargo#2486 it shouldn't miscompile anything, but if they start locking on each other we will have make jobs waiting that could have been doing something else.Signed-off-by: Miguel Ojeda miguel.ojeda.sandonis@gmail.com