Re: [PATCH 09/13] Samples: Rust examples

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Apr 14, 2021 at 04:24:45PM -0700, Nick Desaulniers wrote:
> On Wed, Apr 14, 2021 at 12:35 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Wed, Apr 14, 2021 at 11:47 AM <ojeda@kernel.org> wrote:
> > >
> > > From: Miguel Ojeda <ojeda@kernel.org>
> > >
> > > 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