Re: [TECH TOPIC] Rust for Linux

[Greg KH <greg@kroah.com>]

On Thu, Jul 08, 2021 at 03:55:31PM +0200, Miguel Ojeda wrote:
>     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.

Ok, great, then how would you handle the kref issue where you need an
external lock to properly handle the reference counting logic in Rust?
Why is C so "bad" here that we require a lock but Rust would not?

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

Ok, what "model" would be better?  We need a "base object" that has
solid lifecycle rules.  Right now we do have that, but it's just not the
easiest to use for complex objects where we have multiple objects with
different lifecycles that all interact together.  The v4l example is the
best, but the input layer also has this type of issue.

thanks,

greg k-h