Hi Linus,
Please pull the initial Rust support for v6.1-rc1. The tree has a recent
base, but has fundamentally been in linux-next for a year and a half[1].
It's been updated based on feedback from the Kernel Maintainer's Summit,
and to gain recent Reviewed-by: tags. Miguel is the primary maintainer,
with me helping where needed/wanted. Our plan is for the tree to switch to
the standard non-rebasing practice once this initial infrastructure series
lands. The contents are the absolute minimum to get Rust code building
in the kernel, with many more interfaces[2] (and drivers[3]) on the way.
Expected conflicts are minimal:
- docs-next: https://lore.kernel.org/lkml/[email protected]/
Thanks!
-Kees
[1] https://lwn.net/Articles/849849/
[2] https://github.com/Rust-for-Linux/linux/commits/rust
[3] NVMe: https://github.com/metaspace/rust-linux/commit/d88c3744d6cbdf11767e08bad56cbfb67c4c96d0
9p: https://github.com/wedsonaf/linux/commit/9367032607f7670de0ba1537cf09ab0f4365a338
M1 GPU: https://github.com/AsahiLinux/linux/commits/gpu/rust-wip
The following changes since commit f76349cf41451c5c42a99f18a9163377e4b364ff:
Linux 6.0-rc7 (2022-09-25 14:01:02 -0700)
are available in the Git repository at:
https://github.com/Rust-for-Linux/linux.git tags/rust-v6.1-rc1
for you to fetch changes up to 615131b8e9bcd88e2d3ef78a4954ff4abfbb1fb7:
MAINTAINERS: Rust (2022-09-28 09:05:20 +0200)
----------------------------------------------------------------
Rust introduction for v6.1-rc1
The initial support of Rust-for-Linux comes in roughly 4 areas:
- Kernel internals (kallsyms expansion for Rust symbols, %pA format)
- Kbuild infrastructure (Rust build rules and support scripts)
- Rust crates and bindings for initial minimum viable build
- Rust kernel documentation and samples
Rust support has been in linux-next for a year and a half now, and the
short log doesn't do justice to the number of people who have contributed
both to the Linux kernel side but also to the upstream Rust side to
support the kernel's needs. Thanks to these 173 people, and many more,
who have been involved in all kinds of ways:
Miguel Ojeda, Wedson Almeida Filho, Alex Gaynor, Boqun Feng, Gary Guo,
Bj?rn Roy Baron, Andreas Hindborg, Adam Bratschi-Kaye, Benno Lossin,
Maciej Falkowski, Finn Behrens, Sven Van Asbroeck, Asahi Lina, FUJITA
Tomonori, John Baublitz, Wei Liu, Geoffrey Thomas, Philip Herron,
Arthur Cohen, David Faust, Antoni Boucher, Philip Li, Yujie Liu,
Jonathan Corbet, Greg Kroah-Hartman, Paul E. McKenney, Josh Triplett,
Kent Overstreet, David Gow, Alice Ryhl, Robin Randhawa, Kees Cook,
Nick Desaulniers, Matthew Wilcox, Linus Walleij, Joe Perches, Michael
Ellerman, Petr Mladek, Masahiro Yamada, Arnaldo Carvalho de Melo,
Andrii Nakryiko, Konstantin Shelekhin, Rasmus Villemoes, Konstantin
Ryabitsev, Stephen Rothwell, Andy Shevchenko, Sergey Senozhatsky, John
Paul Adrian Glaubitz, David Laight, Nathan Chancellor, Jonathan
Cameron, Daniel Latypov, Shuah Khan, Brendan Higgins, Julia Lawall,
Laurent Pinchart, Geert Uytterhoeven, Akira Yokosawa, Pavel Machek,
David S. Miller, John Hawley, James Bottomley, Arnd Bergmann,
Christian Brauner, Dan Robertson, Nicholas Piggin, Zhouyi Zhou, Elena
Zannoni, Jose E. Marchesi, Leon Romanovsky, Will Deacon, Richard
Weinberger, Randy Dunlap, Paolo Bonzini, Roland Dreier, Mark Brown,
Sasha Levin, Ted Ts'o, Steven Rostedt, Jarkko Sakkinen, Michal
Kubecek, Marco Elver, Al Viro, Keith Busch, Johannes Berg, Jan Kara,
David Sterba, Connor Kuehl, Andy Lutomirski, Andrew Lunn, Alexandre
Belloni, Peter Zijlstra, Russell King, Eric W. Biederman, Willy
Tarreau, Christoph Hellwig, Emilio Cobos ?lvarez, Christian Poveda,
Mark Rousskov, John Ericson, TennyZhuang, Xuanwo, Daniel Paoliello,
Manish Goregaokar, comex, Josh Stone, Stephan Sokolow, Philipp Krones,
Guillaume Gomez, Joshua Nelson, Mats Larsen, Marc Poulhi?s, Samantha
Miller, Esteban Blanc, Martin Schmidt, Martin Rodriguez Reboredo,
Daniel Xu, Viresh Kumar, Bartosz Golaszewski, Vegard Nossum, Milan
Landaverde, Dariusz Sosnowski, Yuki Okushi, Matthew Bakhtiari, Wu
XiangCheng, Tiago Lam, Boris-Chengbiao Zhou, Sumera Priyadarsini,
Viktor Garske, Niklas Mohrin, N?ndor Istv?n Kr?cser, Morgan Bartlett,
Miguel Cano, L?o Lanteri Thauvin, Julian Merkle, Andreas Reindl,
Jiapeng Chong, Fox Chen, Douglas Su, Antonio Terceiro, SeongJae Park,
Sergio Gonz?lez Collado, Ngo Iok Ui (Wu Yu Wei), Joshua Abraham,
Milan, Daniel Kolsoi, ahomescu, Manas, Luis Gerhorst, Li Hongyu,
Philipp Gesang, Russell Currey, Jalil David Salam? Messina, Jon Olson,
Raghvender, Angelos, Kaviraj Kanagaraj, Paul R?mer, Sladyn Nunes,
Mauro Balad?s, Hsiang-Cheng Yang, Abhik Jain, Hongyu Li, Sean Nash,
Yuheng Su, Peng Hao, Anhad Singh, Roel Kluin, Sara Saa, Geert
Stappers, Garrett LeSage, IFo Hancroft, and Linus Torvalds.
----------------------------------------------------------------
Boqun Feng (2):
kallsyms: use `ARRAY_SIZE` instead of hardcoded size
kallsyms: avoid hardcoding buffer size
Daniel Xu (1):
scripts: add `is_rust_module.sh`
Gary Guo (1):
vsprintf: add new `%pA` format specifier
Miguel Ojeda (22):
kallsyms: add static relationship between `KSYM_NAME_LEN{,_BUFFER}`
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
rust: add C helpers
rust: import upstream `alloc` crate
rust: adapt `alloc` crate to the kernel
rust: add `compiler_builtins` crate
rust: add `macros` crate
rust: add `bindings` crate
rust: export generated symbols
scripts: checkpatch: diagnose uses of `%pA` in the C side as errors
scripts: checkpatch: enable language-independent checks for Rust
scripts: decode_stacktrace: demangle Rust symbols
scripts: add `generate_rust_analyzer.py`
scripts: add `generate_rust_target.rs`
scripts: add `rust_is_available.sh`
rust: add `.rustfmt.toml`
Kbuild: add Rust support
docs: add Rust documentation
x86: enable initial Rust support
samples: add first Rust examples
MAINTAINERS: Rust
Wedson Almeida Filho (1):
rust: add `kernel` crate
.gitignore | 6 +
.rustfmt.toml | 12 +
Documentation/core-api/printk-formats.rst | 10 +
Documentation/doc-guide/kernel-doc.rst | 3 +
Documentation/index.rst | 1 +
Documentation/kbuild/kbuild.rst | 17 +
Documentation/kbuild/makefiles.rst | 50 +-
Documentation/process/changes.rst | 41 +
Documentation/rust/arch-support.rst | 19 +
Documentation/rust/coding-guidelines.rst | 216 ++
Documentation/rust/general-information.rst | 79 +
Documentation/rust/index.rst | 22 +
Documentation/rust/quick-start.rst | 232 ++
MAINTAINERS | 18 +
Makefile | 172 +-
arch/Kconfig | 6 +
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 10 +
include/linux/compiler_types.h | 6 +-
include/linux/kallsyms.h | 2 +-
init/Kconfig | 46 +-
kernel/configs/rust.config | 1 +
kernel/kallsyms.c | 26 +-
kernel/livepatch/core.c | 4 +-
lib/Kconfig.debug | 34 +
lib/vsprintf.c | 13 +
rust/.gitignore | 8 +
rust/Makefile | 381 ++++
rust/alloc/README.md | 33 +
rust/alloc/alloc.rs | 440 ++++
rust/alloc/borrow.rs | 498 ++++
rust/alloc/boxed.rs | 2028 +++++++++++++++++
rust/alloc/collections/mod.rs | 156 ++
rust/alloc/lib.rs | 244 ++
rust/alloc/raw_vec.rs | 527 +++++
rust/alloc/slice.rs | 1204 ++++++++++
rust/alloc/vec/drain.rs | 186 ++
rust/alloc/vec/drain_filter.rs | 145 ++
rust/alloc/vec/into_iter.rs | 366 +++
rust/alloc/vec/is_zero.rs | 120 +
rust/alloc/vec/mod.rs | 3140 ++++++++++++++++++++++++++
rust/alloc/vec/partial_eq.rs | 49 +
rust/bindgen_parameters | 21 +
rust/bindings/bindings_helper.h | 13 +
rust/bindings/lib.rs | 53 +
rust/compiler_builtins.rs | 63 +
rust/exports.c | 21 +
rust/helpers.c | 51 +
rust/kernel/allocator.rs | 64 +
rust/kernel/error.rs | 59 +
rust/kernel/lib.rs | 78 +
rust/kernel/prelude.rs | 20 +
rust/kernel/print.rs | 198 ++
rust/kernel/str.rs | 72 +
rust/macros/helpers.rs | 51 +
rust/macros/lib.rs | 72 +
rust/macros/module.rs | 282 +++
samples/Kconfig | 2 +
samples/Makefile | 1 +
samples/rust/Kconfig | 30 +
samples/rust/Makefile | 5 +
samples/rust/hostprogs/.gitignore | 3 +
samples/rust/hostprogs/Makefile | 5 +
samples/rust/hostprogs/a.rs | 7 +
samples/rust/hostprogs/b.rs | 5 +
samples/rust/hostprogs/single.rs | 12 +
samples/rust/rust_minimal.rs | 38 +
scripts/.gitignore | 1 +
scripts/Kconfig.include | 6 +-
scripts/Makefile | 3 +
scripts/Makefile.build | 60 +
scripts/Makefile.debug | 8 +
scripts/Makefile.host | 34 +-
scripts/Makefile.lib | 12 +
scripts/Makefile.modfinal | 8 +-
scripts/cc-version.sh | 12 +-
scripts/checkpatch.pl | 12 +-
scripts/decode_stacktrace.sh | 14 +
scripts/generate_rust_analyzer.py | 135 ++
scripts/generate_rust_target.rs | 182 ++
scripts/is_rust_module.sh | 16 +
scripts/kallsyms.c | 53 +-
scripts/kconfig/confdata.c | 75 +
scripts/min-tool-version.sh | 6 +
scripts/rust_is_available.sh | 160 ++
scripts/rust_is_available_bindgen_libclang.h | 2 +
tools/include/linux/kallsyms.h | 2 +-
tools/lib/perf/include/perf/event.h | 2 +-
tools/lib/symbol/kallsyms.h | 2 +-
89 files changed, 12552 insertions(+), 51 deletions(-)
create mode 100644 .rustfmt.toml
create mode 100644 Documentation/rust/arch-support.rst
create mode 100644 Documentation/rust/coding-guidelines.rst
create mode 100644 Documentation/rust/general-information.rst
create mode 100644 Documentation/rust/index.rst
create mode 100644 Documentation/rust/quick-start.rst
create mode 100644 kernel/configs/rust.config
create mode 100644 rust/.gitignore
create mode 100644 rust/Makefile
create mode 100644 rust/alloc/README.md
create mode 100644 rust/alloc/alloc.rs
create mode 100644 rust/alloc/borrow.rs
create mode 100644 rust/alloc/boxed.rs
create mode 100644 rust/alloc/collections/mod.rs
create mode 100644 rust/alloc/lib.rs
create mode 100644 rust/alloc/raw_vec.rs
create mode 100644 rust/alloc/slice.rs
create mode 100644 rust/alloc/vec/drain.rs
create mode 100644 rust/alloc/vec/drain_filter.rs
create mode 100644 rust/alloc/vec/into_iter.rs
create mode 100644 rust/alloc/vec/is_zero.rs
create mode 100644 rust/alloc/vec/mod.rs
create mode 100644 rust/alloc/vec/partial_eq.rs
create mode 100644 rust/bindgen_parameters
create mode 100644 rust/bindings/bindings_helper.h
create mode 100644 rust/bindings/lib.rs
create mode 100644 rust/compiler_builtins.rs
create mode 100644 rust/exports.c
create mode 100644 rust/helpers.c
create mode 100644 rust/kernel/allocator.rs
create mode 100644 rust/kernel/error.rs
create mode 100644 rust/kernel/lib.rs
create mode 100644 rust/kernel/prelude.rs
create mode 100644 rust/kernel/print.rs
create mode 100644 rust/kernel/str.rs
create mode 100644 rust/macros/helpers.rs
create mode 100644 rust/macros/lib.rs
create mode 100644 rust/macros/module.rs
create mode 100644 samples/rust/Kconfig
create mode 100644 samples/rust/Makefile
create mode 100644 samples/rust/hostprogs/.gitignore
create mode 100644 samples/rust/hostprogs/Makefile
create mode 100644 samples/rust/hostprogs/a.rs
create mode 100644 samples/rust/hostprogs/b.rs
create mode 100644 samples/rust/hostprogs/single.rs
create mode 100644 samples/rust/rust_minimal.rs
create mode 100755 scripts/generate_rust_analyzer.py
create mode 100644 scripts/generate_rust_target.rs
create mode 100755 scripts/is_rust_module.sh
create mode 100755 scripts/rust_is_available.sh
create mode 100644 scripts/rust_is_available_bindgen_libclang.h
--
Kees Cook
On Sun, Oct 2, 2022 at 12:59 AM Kees Cook <[email protected]> wrote:
>
> Hi Linus,
>
> Please pull the initial Rust support for v6.1-rc1. The tree has a recent
> base, but has fundamentally been in linux-next for a year and a half[1].
> It's been updated based on feedback from the Kernel Maintainer's Summit,
> and to gain recent Reviewed-by: tags. Miguel is the primary maintainer,
> with me helping where needed/wanted. Our plan is for the tree to switch to
> the standard non-rebasing practice once this initial infrastructure series
> lands. The contents are the absolute minimum to get Rust code building
> in the kernel, with many more interfaces[2] (and drivers[3]) on the way.
>
> Expected conflicts are minimal:
> - docs-next: https://lore.kernel.org/lkml/[email protected]/
Also, conflicts against the Kbuild tree.
linux-next 20220930 fails to build with CONFIG_RUST=y because the merge
conflicts between Kbuild and Rust trees were not correctly resolved.
I will try my best to address merge conflicts when I send my pull request.
--
Best Regards
Masahiro Yamada
On Sun, Oct 2, 2022 at 12:50 AM Kees Cook <[email protected]> wrote:
>
> Ah, yes. Apologies; I missed this while checking the list. The latest
> I found are from 9/28:
> https://lore.kernel.org/linux-next/[email protected]/
> Miguel verified the conflict resolution at the time.
Yeah, the `obj-$(CONFIG_RUST)` line in `Kbuild` is in that resolution,
but I don't see it on linux-next 20220930.
Cheers,
Miguel
On Sun, Oct 02, 2022 at 05:21:17AM +0900, Masahiro Yamada wrote:
> On Sun, Oct 2, 2022 at 12:59 AM Kees Cook <[email protected]> wrote:
> >
> > Hi Linus,
> >
> > Please pull the initial Rust support for v6.1-rc1. The tree has a recent
> > base, but has fundamentally been in linux-next for a year and a half[1].
> > It's been updated based on feedback from the Kernel Maintainer's Summit,
> > and to gain recent Reviewed-by: tags. Miguel is the primary maintainer,
> > with me helping where needed/wanted. Our plan is for the tree to switch to
> > the standard non-rebasing practice once this initial infrastructure series
> > lands. The contents are the absolute minimum to get Rust code building
> > in the kernel, with many more interfaces[2] (and drivers[3]) on the way.
> >
> > Expected conflicts are minimal:
> > - docs-next: https://lore.kernel.org/lkml/[email protected]/
>
>
> Also, conflicts against the Kbuild tree.
Ah, yes. Apologies; I missed this while checking the list. The latest
I found are from 9/28:
https://lore.kernel.org/linux-next/[email protected]/
Miguel verified the conflict resolution at the time.
> linux-next 20220930 fails to build with CONFIG_RUST=y because the merge
> conflicts between Kbuild and Rust trees were not correctly resolved.
Ah, did something change between 28 and 30?
> I will try my best to address merge conflicts when I send my pull request.
Thank you!
--
Kees Cook
On Sat, 2022-10-01 at 08:58 -0700, Kees Cook wrote:
> Hi Linus,
>
> Please pull the initial Rust support for v6.1-rc1. The tree has a recent
> base, but has fundamentally been in linux-next for a year and a half[1].
> It's been updated based on feedback from the Kernel Maintainer's Summit,
> and to gain recent Reviewed-by: tags. Miguel is the primary maintainer,
> with me helping where needed/wanted. Our plan is for the tree to switch to
> the standard non-rebasing practice once this initial infrastructure series
> lands. The contents are the absolute minimum to get Rust code building
> in the kernel, with many more interfaces[2] (and drivers[3]) on the way.
Hi,
As a Linux From Scratch maintainer I have to express some concern.
I think I have the most open attitude to Rust among all Linux From
Scratch members. But this will be just *too* troubling for us.
I'm not against the use of Rust in kernel, but:
1. Current implementation strictly depends on bindgen, which depends on
libclang in turn. It means even if the Rust support land in GCC 13,
we'll still need to build and install the giant LLVM for building the
Rust components in the kernel. Is it possible to use some different
approach (for example, including the binding in the kernel tree)?
2. Squashing all the cmake, LLVM, and Rustc stuff into the Linux From
Scratch book will be extremely painful, but still possible. However, we
currently need "A particular version of the Rust compiler". This is
just annoying. What will happen if a security vulnerability suddenly
shows up in the "particular version" required by a kernel LTS branch?
And from a distro maintainer's point of view this will forces us to
build multiple Rustc versions. I see the reason "the kernel depends on
some unstable Rust features", but then shouldn't we wait for (or urge
the Rustc developers for) the stabilization of these features, instead
of merging Rust into the mainline too quickly? Now they can declare the
victory like "oh, the kernel is now using our language!" but *we* are
paying all costs.
On Tue, Oct 04, 2022 at 01:32:49PM +0800, Xi Ruoyao wrote:
> On Sat, 2022-10-01 at 08:58 -0700, Kees Cook wrote:
> > Hi Linus,
> >
> > Please pull the initial Rust support for v6.1-rc1. The tree has a recent
> > base, but has fundamentally been in linux-next for a year and a half[1].
> > It's been updated based on feedback from the Kernel Maintainer's Summit,
> > and to gain recent Reviewed-by: tags. Miguel is the primary maintainer,
> > with me helping where needed/wanted. Our plan is for the tree to switch to
> > the standard non-rebasing practice once this initial infrastructure series
> > lands. The contents are the absolute minimum to get Rust code building
> > in the kernel, with many more interfaces[2] (and drivers[3]) on the way.
>
> Hi,
>
> As a Linux From Scratch maintainer I have to express some concern.
>
> I think I have the most open attitude to Rust among all Linux From
> Scratch members. But this will be just *too* troubling for us.
>
> I'm not against the use of Rust in kernel, but:
>
> 1. Current implementation strictly depends on bindgen, which depends on
> libclang in turn. It means even if the Rust support land in GCC 13,
> we'll still need to build and install the giant LLVM for building the
> Rust components in the kernel. Is it possible to use some different
> approach (for example, including the binding in the kernel tree)?
>
> 2. Squashing all the cmake, LLVM, and Rustc stuff into the Linux From
> Scratch book will be extremely painful, but still possible. However, we
> currently need "A particular version of the Rust compiler". This is
> just annoying. What will happen if a security vulnerability suddenly
> shows up in the "particular version" required by a kernel LTS branch?
> And from a distro maintainer's point of view this will forces us to
> build multiple Rustc versions. I see the reason "the kernel depends on
> some unstable Rust features", but then shouldn't we wait for (or urge
> the Rustc developers for) the stabilization of these features, instead
> of merging Rust into the mainline too quickly? Now they can declare the
> victory like "oh, the kernel is now using our language!" but *we* are
> paying all costs.
>
Just my 2 cents.
IIUC the Rust support is still in the *experiment* stage, in other
words, the whole thing may get removed if things don't go well. So I
wouldn't recommend any distro to enable it for the LTS kernel or any
kernel used for production.
That said, it may be a good time to start thinking of the list of
prerequisites for distros to enable it. I believe you just mentioned a
few above, so thank you!
As for the "victory of them but cost of us" thing, TBH, we do use the
compiler and other tool from them (and for free), so that's fair ;-)
Besides if the victory make them care more about kernel needs, it's
better ;-)
Regards,
Boqun