| Message ID | 20231104211213.225891-1-yakoyoku@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rust: crates in other kernel directories | expand |
On Sun, Nov 5, 2023 at 6:12 AM Martin Rodriguez Reboredo <yakoyoku@gmail.com> wrote: > > This RFC provides makes possible to have bindings for kernel subsystems > that are compiled as modules. > > Previously, if you wanted to have Rust bindings for a subsystem, like > AMBA for example, you had to put it under `rust/kernel/` so it came > part of the `kernel` crate, but this came with many downsides. Namely > if you compiled said subsystem as a module you've a dependency on it > from `kernel`, which is linked directly on `vmlinux`. > > So instead of overpopulating `kernel` with a gazillion modules that > throws you into dire straits you should rather have the bindings in the > same directory as the subsystem you want to bind with and link it to > it. > > With this patch Rust sources can be compiled into libraries for them to > be consumed. These libraries are ar archives that follow the `.rlib` > structure, namely a libfoo.rlib thin archive with a foo.foo.o object > and a libfoo.rmeta rustc metadata as members. Such Rust crates get > their symbols exposed and the `bindings` crate is made available for > them. > > Also included there's a sample usage of this in another patch, but it > is not meant to be merged as it remains as an example. > > If you want to use a crate with your Rust module just add a `rust-libs` > variable in your Makefile with a value of the relative directory of > said crate plus its name, e.g. > > # Link with the foo crate > rust-libs += ../path/to/foo I will not provide a line-by-line review. Just one thing I'd like to point out. You assume the library (drivers/usb/core/*) is built before its consumers (samples/rust/*). If Kbuild ends up with building lib consumers first, it will be a build error. Kbuild descends into multiple directories in parallel building. You cannot predict which directory is built first. > Martin Rodriguez Reboredo (2): > kbuild: Build Rust crates as libraries > samples: rust: Add USB sample bindings > > .gitignore | 2 ++ > Makefile | 4 ++-- > drivers/usb/core/Kconfig | 7 ++++++ > drivers/usb/core/Makefile | 3 +++ > drivers/usb/core/usb.rs | 13 ++++++++++ > rust/bindings/bindings_helper.h | 1 + > samples/rust/Kconfig | 10 ++++++++ > samples/rust/Makefile | 3 +++ > samples/rust/rust_usb_simple.rs | 22 +++++++++++++++++ > scripts/Makefile.build | 42 ++++++++++++++++++++++++++++++--- > scripts/Makefile.lib | 20 ++++++++++++---- > scripts/Makefile.modfinal | 9 +++++-- > 12 files changed, 125 insertions(+), 11 deletions(-) > create mode 100644 drivers/usb/core/usb.rs > create mode 100644 samples/rust/rust_usb_simple.rs > > -- > 2.42.1 >
On 11/13/23 11:13, Masahiro Yamada wrote: > [...] > > I will not provide a line-by-line review. > > > Just one thing I'd like to point out. > > You assume the library (drivers/usb/core/*) > is built before its consumers (samples/rust/*). > > If Kbuild ends up with building lib consumers first, > it will be a build error. > > > > Kbuild descends into multiple directories in parallel building. > > You cannot predict which directory is built first. > > [...] Thinking with what you've said the same thing might apply to any Rust written code that depends on crates under the `rust` dir. Adding Make dependencies to object code made from `.rs` will be required if so, assuming that Kbuild is intelligent enough to build the crates first.
On Mon, Feb 19, 2024 at 1:11 AM Martin Rodriguez Reboredo <yakoyoku@gmail.com> wrote: > > On 11/13/23 11:13, Masahiro Yamada wrote: > > [...] > > > > I will not provide a line-by-line review. > > > > > > Just one thing I'd like to point out. > > > > You assume the library (drivers/usb/core/*) > > is built before its consumers (samples/rust/*). > > > > If Kbuild ends up with building lib consumers first, > > it will be a build error. > > > > > > > > Kbuild descends into multiple directories in parallel building. > > > > You cannot predict which directory is built first. > > > > [...] > > Thinking with what you've said the same thing might apply to any Rust > written code that depends on crates under the `rust` dir. Adding > Make dependencies to object code made from `.rs` will be required if so, > assuming that Kbuild is intelligent enough to build the crates first. rust/Makefile specifies dependencies between crates. I do not know how to specify crate dependencies across multiple Makefiles, like you did in drivers/usb/core/Makefile and samples/rust/Makefile.
Hi, So I realize this is an old patch, but I didn't find another version, and discussions seemed ongoing at least a month ago. I also came across it pretty randomly. Anyway, question: > If you want to use a crate with your Rust module just add a `rust-libs` > variable in your Makefile with a value of the relative directory of > said crate plus its name, e.g. > > # Link with the foo crate > rust-libs += ../path/to/foo Should this perhaps be relative to the kernel's root dir instead? If I'm reading this correctly, then a hypothetical rust wireless driver that lives in drivers/net/wireless/<vendor>/<name>/ using some wireless rust infrastructure would probably end up with something like rust-libs += ../../../../../net/mac80211/rust/ or whatever, which seems rather odd vs. rust-libs += net/mac80211/rust/ Seems to me that chances are that subsystems/drivers that have rust infrastructure will not necessarily have them close to each other, like in this example? You have this in the sample too: +rust-libs := ../../drivers/usb/core/usb but it's less pronounced since it's just samples/rust/ :) johannes
This RFC provides makes possible to have bindings for kernel subsystems that are compiled as modules. Previously, if you wanted to have Rust bindings for a subsystem, like AMBA for example, you had to put it under `rust/kernel/` so it came part of the `kernel` crate, but this came with many downsides. Namely if you compiled said subsystem as a module you've a dependency on it from `kernel`, which is linked directly on `vmlinux`. So instead of overpopulating `kernel` with a gazillion modules that throws you into dire straits you should rather have the bindings in the same directory as the subsystem you want to bind with and link it to it. With this patch Rust sources can be compiled into libraries for them to be consumed. These libraries are ar archives that follow the `.rlib` structure, namely a libfoo.rlib thin archive with a foo.foo.o object and a libfoo.rmeta rustc metadata as members. Such Rust crates get their symbols exposed and the `bindings` crate is made available for them. Also included there's a sample usage of this in another patch, but it is not meant to be merged as it remains as an example. If you want to use a crate with your Rust module just add a `rust-libs` variable in your Makefile with a value of the relative directory of said crate plus its name, e.g. # Link with the foo crate rust-libs += ../path/to/foo Martin Rodriguez Reboredo (2): kbuild: Build Rust crates as libraries samples: rust: Add USB sample bindings .gitignore | 2 ++ Makefile | 4 ++-- drivers/usb/core/Kconfig | 7 ++++++ drivers/usb/core/Makefile | 3 +++ drivers/usb/core/usb.rs | 13 ++++++++++ rust/bindings/bindings_helper.h | 1 + samples/rust/Kconfig | 10 ++++++++ samples/rust/Makefile | 3 +++ samples/rust/rust_usb_simple.rs | 22 +++++++++++++++++ scripts/Makefile.build | 42 ++++++++++++++++++++++++++++++--- scripts/Makefile.lib | 20 ++++++++++++---- scripts/Makefile.modfinal | 9 +++++-- 12 files changed, 125 insertions(+), 11 deletions(-) create mode 100644 drivers/usb/core/usb.rs create mode 100644 samples/rust/rust_usb_simple.rs