Re: [PATCH 09/13] Samples: Rust examples
On Fri, Apr 16, 2021 at 09:07:10AM -0400, Sven Van Asbroeck wrote: > On Thu, Apr 15, 2021 at 3:11 AM Greg Kroah-Hartman > wrote: > > > > I've been talking with the developers here about doing a "real" driver > > Would it be beneficial if the device h/w targeted by the "real" Rust > driver has QEMU emulation? Perhaps in addition to physical silicon. Again, as was reported, a nvme driver falls into that category today, no need to look very far. thanks, greg k-h
Re: [PATCH 09/13] Samples: Rust examples
On Thu, Apr 15, 2021 at 3:11 AM Greg Kroah-Hartman wrote: > > I've been talking with the developers here about doing a "real" driver Would it be beneficial if the device h/w targeted by the "real" Rust driver has QEMU emulation? Perhaps in addition to physical silicon. If developers don't need access to physical hardware, they might be more likely to get involved with Linux/Rust. Also, I'm guessing QEMU allows us to embed the emulated device into a variety of board architectures: x86_64, arm64, powerpc, etc. which could be useful in smoking out architecture-specific Rust driver issues. Sven
Re: [PATCH 09/13] Samples: Rust examples
Hi, On 14/04/2021 21:42, Miguel Ojeda wrote: > On Wed, Apr 14, 2021 at 9:34 PM Linus Torvalds > wrote: >> >> Honestly, I'd like to see a real example. This is fine for testing, >> but I'd like to see something a bit more real, and a bit less special >> than the Android "binder" WIP that comes a few patches later. >> >> Would there be some kind of real driver or something that people could >> use as a example of a real piece of code that actually does something >> meaningful? > > Yeah, we are planning to write a couple of drivers that talk to actual > hardware. Not sure which ones we will do, but we will have them > written. I’m curious what’s the procedure and approach in general to adding new APIs? I was thinking of trying to port my driver but it needs USB HID and either LEDs or hwrandom (depending on which part I start porting first), so obviously it’s not doable right now, but I’m thinking about maybe helping with at least some of those. -- Cheers, Andrej
Re: [PATCH 09/13] Samples: Rust examples
On Thu, Apr 15, 2021 at 9:10 AM Greg Kroah-Hartman wrote: > > Let's see what happens here, this patchset is a great start that > provides the core "here's how to build rust in the kernel build system", > which was a non-trivial engineering effort. Hats off to them that "all" > I had to do was successfully install the proper rust compiler on my > system (not these developers fault), and then building the kernel code > here did "just work". That's a major achievement. Thanks a lot for the kind words and for trying it! Let's see if we can make this happen. Cheers, Miguel
Re: [PATCH 09/13] Samples: Rust examples
On Thu, Apr 15, 2021 at 12:10 AM Greg Kroah-Hartman wrote: > > On Wed, Apr 14, 2021 at 04:24:45PM -0700, Nick Desaulniers wrote: > > On Wed, Apr 14, 2021 at 12:35 PM Linus Torvalds > > wrote: > > > > > > On Wed, Apr 14, 2021 at 11:47 AM wrote: > > > > > > > > From: Miguel Ojeda > > > > > > > > A set of Rust modules that showcase how Rust modules look like > > > > and how to use the abstracted kernel features. > > > > > > Honestly, I'd like to see a real example. This is fine for testing, > > > but I'd like to see something a bit more real, and a bit less special > > > than the Android "binder" WIP that comes a few patches later. > > > > > > Would there be some kind of real driver or something that people could > > > use as a example of a real piece of code that actually does something > > > meaningful? > > > > Are you suggesting that they "rewrite it in Rust?" :^P *ducks* > > Well, that's what they are doing here with the binder code :) I know, but imagine the meme magic if Linus said literally that! Missed opportunity. > Seriously, binder is not a "normal" driver by any means, the only way > you can squint at it and consider it a driver is that it has a char > device node that it uses to talk to userspace with. Other than that, > it's very stand-alone and does crazy things to kernel internals, which > makes it a good canidate for a rust rewrite in that it is easy to > benchmark and no one outside of one ecosystem relies on it. > > The binder code also shows that there is a bunch of "frameworks" that > need to be ported to rust to get it to work, I think the majority of the > rust code for binder is just trying to implement core kernel things like > linked lists and the like. That will need to move into the rust kernel > core eventually. > > The binder rewrite here also is missing a number of features that the > in-kernel binder code has gotten over the years, so it is not > feature-complete by any means yet, it's still a "toy example". > > > (sorry, I couldn't help myself) Perhaps it would be a good exercise to > > demonstrate some of the benefits of using Rust for driver work? > > I've been talking with the developers here about doing a "real" driver, > as the interaction between the rust code which has one set of lifetime > rules, and the driver core/model which has a different set of lifetime > rules, is going to be what shows if this actually can be done or not. > If the two can not successfully be "bridged" together, then there will > be major issues. > > Matthew points out that a nvme driver would be a good example, and I > have a few other thoughts about what would be good to start with for > some of the basics that driver authors deal with on a daily basis > (platform driver, gpio driver, pcspkr driver, /dev/zero replacement), or > that might be more suited for a "safety critical language use-case" like > the HID parser or maybe the ACPI parser (but that falls into the rewrite > category that we want to stay away from for now...) Sage advice, and it won't hurt to come back with more examples. Perhaps folks in the Rust community who have been itching to get involved in developing their favorite operating system might be interested? One technique for new language adoption I've seen at Mozilla and Google has been a moratorium that any code in needs to have a fallback in in case doesn't work out. Perhaps that would be a good policy to consider; you MAY rewrite existing drivers in Rust, but you MUST provide a C implementation or ensure one exists as fallback until further notice. That might also allay targetability concerns. > Let's see what happens here, this patchset is a great start that > provides the core "here's how to build rust in the kernel build system", > which was a non-trivial engineering effort. Hats off to them that "all" > I had to do was successfully install the proper rust compiler on my > system (not these developers fault), and then building the kernel code > here did "just work". That's a major achievement. For sure, kudos folks and thanks Greg for taking the time to try it out and provide feedback plus ideas for more interesting drivers. -- Thanks, ~Nick Desaulniers
Re: [PATCH 09/13] Samples: Rust examples
On Wed, Apr 14, 2021 at 04:24:45PM -0700, Nick Desaulniers wrote: > On Wed, Apr 14, 2021 at 12:35 PM Linus Torvalds > wrote: > > > > On Wed, Apr 14, 2021 at 11:47 AM wrote: > > > > > > From: Miguel Ojeda > > > > > > A set of Rust modules that showcase how Rust modules look like > > > and how to use the abstracted kernel features. > > > > Honestly, I'd like to see a real example. This is fine for testing, > > but I'd like to see something a bit more real, and a bit less special > > than the Android "binder" WIP that comes a few patches later. > > > > Would there be some kind of real driver or something that people could > > use as a example of a real piece of code that actually does something > > meaningful? > > Are you suggesting that they "rewrite it in Rust?" :^P *ducks* Well, that's what they are doing here with the binder code :) Seriously, binder is not a "normal" driver by any means, the only way you can squint at it and consider it a driver is that it has a char device node that it uses to talk to userspace with. Other than that, it's very stand-alone and does crazy things to kernel internals, which makes it a good canidate for a rust rewrite in that it is easy to benchmark and no one outside of one ecosystem relies on it. The binder code also shows that there is a bunch of "frameworks" that need to be ported to rust to get it to work, I think the majority of the rust code for binder is just trying to implement core kernel things like linked lists and the like. That will need to move into the rust kernel core eventually. The binder rewrite here also is missing a number of features that the in-kernel binder code has gotten over the years, so it is not feature-complete by any means yet, it's still a "toy example". > (sorry, I couldn't help myself) Perhaps it would be a good exercise to > demonstrate some of the benefits of using Rust for driver work? I've been talking with the developers here about doing a "real" driver, as the interaction between the rust code which has one set of lifetime rules, and the driver core/model which has a different set of lifetime rules, is going to be what shows if this actually can be done or not. If the two can not successfully be "bridged" together, then there will be major issues. Matthew points out that a nvme driver would be a good example, and I have a few other thoughts about what would be good to start with for some of the basics that driver authors deal with on a daily basis (platform driver, gpio driver, pcspkr driver, /dev/zero replacement), or that might be more suited for a "safety critical language use-case" like the HID parser or maybe the ACPI parser (but that falls into the rewrite category that we want to stay away from for now...) Let's see what happens here, this patchset is a great start that provides the core "here's how to build rust in the kernel build system", which was a non-trivial engineering effort. Hats off to them that "all" I had to do was successfully install the proper rust compiler on my system (not these developers fault), and then building the kernel code here did "just work". That's a major achievement. thanks, greg k-h
Re: [PATCH 09/13] Samples: Rust examples
On Wed, Apr 14, 2021 at 12:35 PM Linus Torvalds wrote: > > On Wed, Apr 14, 2021 at 11:47 AM wrote: > > > > From: Miguel Ojeda > > > > A set of Rust modules that showcase how Rust modules look like > > and how to use the abstracted kernel features. > > Honestly, I'd like to see a real example. This is fine for testing, > but I'd like to see something a bit more real, and a bit less special > than the Android "binder" WIP that comes a few patches later. > > Would there be some kind of real driver or something that people could > use as a example of a real piece of code that actually does something > meaningful? Are you suggesting that they "rewrite it in Rust?" :^P *ducks* (sorry, I couldn't help myself) Perhaps it would be a good exercise to demonstrate some of the benefits of using Rust for driver work? -- Thanks, ~Nick Desaulniers
Re: [PATCH 09/13] Samples: Rust examples
On Wed, Apr 14, 2021 at 09:42:26PM +0200, Miguel Ojeda wrote: > On Wed, Apr 14, 2021 at 9:34 PM Linus Torvalds > wrote: > > > > Honestly, I'd like to see a real example. This is fine for testing, > > but I'd like to see something a bit more real, and a bit less special > > than the Android "binder" WIP that comes a few patches later. > > > > Would there be some kind of real driver or something that people could > > use as a example of a real piece of code that actually does something > > meaningful? > > Yeah, we are planning to write a couple of drivers that talk to actual > hardware. Not sure which ones we will do, but we will have them > written. I'd suggest NVMe as a target. It's readily available, both as real hardware and in (eg) qemu. The spec is freely available, and most devices come pretty close to conforming to the spec until you start to push hard at the edges. Also then you can do performance tests and see where you might want to focus performance efforts.
Re: [PATCH 09/13] Samples: Rust examples
On Wed, Apr 14, 2021 at 9:34 PM Linus Torvalds wrote: > > Honestly, I'd like to see a real example. This is fine for testing, > but I'd like to see something a bit more real, and a bit less special > than the Android "binder" WIP that comes a few patches later. > > Would there be some kind of real driver or something that people could > use as a example of a real piece of code that actually does something > meaningful? Yeah, we are planning to write a couple of drivers that talk to actual hardware. Not sure which ones we will do, but we will have them written. Cheers, Miguel
Re: [PATCH 09/13] Samples: Rust examples
On Wed, Apr 14, 2021 at 11:47 AM wrote: > > From: Miguel Ojeda > > A set of Rust modules that showcase how Rust modules look like > and how to use the abstracted kernel features. Honestly, I'd like to see a real example. This is fine for testing, but I'd like to see something a bit more real, and a bit less special than the Android "binder" WIP that comes a few patches later. Would there be some kind of real driver or something that people could use as a example of a real piece of code that actually does something meaningful? Linus
[PATCH 09/13] Samples: Rust examples
From: Miguel Ojeda A set of Rust modules that showcase how Rust modules look like and how to use the abstracted kernel features. At the moment we also use them as poor man's tests in our CI. However, we plan to implement a proper testing framework. The semaphore sample comes with a C version for comparison. Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Geoffrey Thomas Signed-off-by: Geoffrey Thomas Co-developed-by: Finn Behrens Signed-off-by: Finn Behrens Co-developed-by: Adam Bratschi-Kaye Signed-off-by: Adam Bratschi-Kaye Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Signed-off-by: Miguel Ojeda --- samples/Kconfig| 2 + samples/Makefile | 1 + samples/rust/Kconfig | 103 samples/rust/Makefile | 11 ++ samples/rust/rust_chrdev.rs| 66 samples/rust/rust_minimal.rs | 40 + samples/rust/rust_miscdev.rs | 145 + samples/rust/rust_module_parameters.rs | 72 + samples/rust/rust_print.rs | 58 +++ samples/rust/rust_semaphore.rs | 178 + samples/rust/rust_semaphore_c.c| 212 + samples/rust/rust_stack_probing.rs | 42 + samples/rust/rust_sync.rs | 84 ++ 13 files changed, 1014 insertions(+) create mode 100644 samples/rust/Kconfig create mode 100644 samples/rust/Makefile create mode 100644 samples/rust/rust_chrdev.rs create mode 100644 samples/rust/rust_minimal.rs create mode 100644 samples/rust/rust_miscdev.rs create mode 100644 samples/rust/rust_module_parameters.rs create mode 100644 samples/rust/rust_print.rs create mode 100644 samples/rust/rust_semaphore.rs create mode 100644 samples/rust/rust_semaphore_c.c create mode 100644 samples/rust/rust_stack_probing.rs create mode 100644 samples/rust/rust_sync.rs diff --git a/samples/Kconfig b/samples/Kconfig index e76cdfc50e25..f1f8ba9bee82 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -216,4 +216,6 @@ config SAMPLE_WATCH_QUEUE Build example userspace program to use the new mount_notify(), sb_notify() syscalls and the KEYCTL_WATCH_KEY keyctl() function. +source "samples/rust/Kconfig" + endif # SAMPLES diff --git a/samples/Makefile b/samples/Makefile index c3392a595e4b..68ba3b3da044 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -29,3 +29,4 @@ obj-$(CONFIG_SAMPLE_INTEL_MEI)+= mei/ subdir-$(CONFIG_SAMPLE_WATCHDOG) += watchdog subdir-$(CONFIG_SAMPLE_WATCH_QUEUE)+= watch_queue obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak/ +obj-$(CONFIG_SAMPLES_RUST) += rust/ diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig new file mode 100644 index ..8eb5d5ebdf00 --- /dev/null +++ b/samples/rust/Kconfig @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0 + +menuconfig SAMPLES_RUST + bool "Rust samples" + depends on RUST + help + You can build sample Rust kernel code here. + + If unsure, say N. + +if SAMPLES_RUST + +config SAMPLE_RUST_MINIMAL + tristate "Minimal" + help + This option builds the Rust minimal module sample. + + To compile this as a module, choose M here: + the module will be called rust_minimal. + + If unsure, say N. + +config SAMPLE_RUST_PRINT + tristate "Printing macros" + help + This option builds the Rust printing macros sample. + + To compile this as a module, choose M here: + the module will be called rust_print. + + If unsure, say N. + +config SAMPLE_RUST_MODULE_PARAMETERS + tristate "Module parameters" + help + This option builds the Rust module parameters sample. + + To compile this as a module, choose M here: + the module will be called rust_module_parameters. + + If unsure, say N. + +config SAMPLE_RUST_SYNC + tristate "Synchronisation primitives" + help + This option builds the Rust synchronisation primitives sample. + + To compile this as a module, choose M here: + the module will be called rust_sync. + + If unsure, say N. + +config SAMPLE_RUST_CHRDEV + tristate "Character device" + help + This option builds the Rust character device sample. + + To compile this as a module, choose M here: + the module will be called rust_chrdev. + + If unsure, say N. + +config SAMPLE_RUST_MISCDEV + tristate "Miscellaneous device" + help + This option builds the Rust miscellaneous device sample. + + To compile this as a module, choose M here: + the module will be called rust_miscdev. + + If unsure, say N. + +config SAMPLE_RUST_STACK_PROBING + tristate "Stack probing" + help + This option builds the Rust s
