Re: [TECH TOPIC] Rust for Linux

[Greg KH <greg@kroah.com>]

On Thu, Jul 08, 2021 at 02:36:40PM +0100, Wedson Almeida Filho wrote:
> On Thu, Jul 08, 2021 at 08:11:10AM +0200, Greg KH wrote:
> > Thanks for the detailed explainations, it seems rust can "get away" with
> > some things with regards to reference counts that the kernel can not.
> > Userspace has it easy, but note that now that rust is not in userspace,
> > dealing with multiple cpus/threads is going to be interesting for the
> > language.
> >
> > So, along those lines, how are you going to tie rust's reference count
> > logic in with the kernel's reference count logic?  How are you going to
> > handle dentries, inodes, kobjects, devices and the like?  That's the
> > real question that I don't seem to see anyone even starting to answer
> > just yet.
> 
> None of what I described before is specific to userspace, but I understand your
> need to see something more concrete.
> 
> I'll describe what we've done for `task_struct` and how lifetimes, aliasing
> rules, sync & send traits help us achieve zero cost (when compared to C) but
> also gives us safety. The intention here is to show that similar things can (and
> will) be done to other kernel reference-counted objects when we get to them.

<snip loads of good stuff here, thanks for helping describe all of this>


> > And that's the reason some of us are asking to see a "real" driver, as
> > those have to deal with these kernel-controlled-reference-counted
> > objects properly (as well as hardware control).  Seeing how that is
> > going to work in this language is going to be the real sign of if this
> > is even going to be possible or not.
> 
> Here's what I'd like to avoid: spending time on something that you all still
> think is not typical enough. Would you be able to point us to a driver that
> would showcase the interactions you'd like to see so that (once we have it in
> Rust) we can have a discussion about the merits of the language?
> 
> Hopefully something with interesting interactions with the kernel, but not
> with overly complex hardware, that is, something that doesn't require us to read
> a 400-page specification to implement.

Examples were provided in the first series that was submitted a few
months ago.  What was wrong with them?  And really, there is no need to
dig through a huge spec, try porting an existing C driver will be much
easier.

But if you didn't like the previous examples (nvme block driver, i2c
driver, gpio driver), how about looking at the drivers used by your
current desktop and picking something that you use today that actually
talks to hardware?

We just want to see something "real", so far nothing posted has touched
hardware, and nothing has had to interact with an existing hardware bus
such that it will be automatically loaded and bind to the hardware
present in the system.

Without showing that Rust can actually work in Linux for a real use
case (and binder is not a real use case outside of Android), and how it
will interact with all of the existing kernel objects and lifetimes we
have today, it's going to be a very hard sell.

thanks,

greg k-h