Re: [TECH TOPIC] Rust for Linux

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

    On Thu, Jul 8, 2021 at 8:11 AM Greg KH <greg@kroah.com> 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.

Regarding parallelism, userspace deals with the same problems, so I do
not see fundamental issues coming up there. The language was designed
with parallelism in mind and is a definite improvement over both C and
C++ in that regard.

> 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

Let me clarify that Rust does not have "reference count logic" in the
sense of some compiler magic (nor a runtime) that somehow "knows" that
there is a reference count going on.

The confusion may come from similarly worded concepts: the
lifetimes/borrowing rules are orthogonal to reference-counting
semantics.

For instance, when Wedson was explaining the lifetime associated to a
reference when e.g. passed into a function:

    fn f(x: &X) {
        ...
    }

That `&X` (a "Rust reference") is unrelated to the "reference" in
"reference-counting semantics".

In fact, Rust's lifetime/reference/borrowing rules apply to all code.
For instance:

    let mut i = 42;

    let r1 = &mut i;
    let r2 = &mut i;

    f(r1, r2)

This code has two "Rust references", but there are no
"reference-counted semantics" at all here, nor any refcount involved.
Yet Rust prevents this code from compiling because you are attempting
to create two mutable "Rust references" that alias the same object.

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

Those cases can be handled, one way or another. We will try to have
something more concrete as soon as possible.

Having said that, if people is discussing how to improve the C model
anyway (i.e. the "cdev/devm_* issues" thread), it could be nice --
longer-term -- if we could also take the chance to discuss how to come
up with a model that suites Rust too. This could lead to simpler code,
more ergonomic abstractions and/or less `unsafe` code.

Cheers,
Miguel