Re: [TECH TOPIC] Rust for Linux

[Andy Lutomirski <luto@kernel.org>]

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

Can you point at a specific example in the kernel tree?  The
lock-and-then-put model is, at the very least, unusual, and the kref
docs talk about it like it's common and self-explanatory as to when
it's needed.  I have personally never encountered a need for this, and
I'd like to know exactly what type of use case you're thinking of.

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