Re: [TECH TOPIC] Rust for Linux

Andy Lutomirski
2021-07-08T19:31:21Z

> 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.

I think that, at least for an initial implementation, erroring out in the !use_dma case would be fine. The !use_dma virtio variant is, in my opinion, a historical error and does not really deserve to survive going forward. The powerpc people may beg to differ. Any port of the !use_dma variant to Rust (or anything that safely manages device memory) will quickly notice that the resulting use of device memory is nonsense and ought not to compile without unsafe annotations in various places. And those unsafe annotations may well deserve comments like /* yes, this is indeed wrong. */.

Fortunately, at least on non-powerpc, you can easily boot a system in the sane use_dma mode. Virtme will do this for you with minimal effort.