Re: [TECH TOPIC] Rust for Linux

Geert Uytterhoeven
2021-07-08T19:35:41Z

Hi Andy,

On Thu, Jul 8, 2021 at 9:31 PM Andy Lutomirski <luto@amacapital.net> wrote:
> > On Jul 8, 2021, at 11:51 AM, Greg KH <greg@kroah.com> wrote:
> > ﻿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?
>
> I would suggest a virtio device. The core virtio guest code is horribly unsafe, and various stakeholders keep trying to make it slightly less unsafe. A Rust implementation of the entire virtio ring (or at least the modern bits) and of some concrete device (virtio-blk?) would be quite nice.

Another deviation from real hardware drivers? ;-)
How many kernel maintainers have experience with writing a virtio driver?

What is wrong with something driving real hardware?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds