Re: [Ksummit-discuss] [TECH TOPIC] Rust

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Sat, 25 Jun 2022 10:15:06 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Sat, 2022-06-25 at 12:45 +0100, Mauro Carvalho Chehab wrote:
> [...]
> > Assuming that we get into a point were all the above happens for
> > subsystem XXX, at the Rust experiment validation point you mentioned
> > above, there will be some possible outcomes:
> > 
> > 1) Rust experiment fails. On such case, the efforts to make the
> > subsystem C code ready to run safe Rust code will be welcomed,
> > as Linux should be safer. The work on providing Rust bindings will 
> > be wasted on such case.   
> 
> Not entirely ... we'll still have gone through the learning exercise of
> how do you do this.  If another language promising additional safety
> features comes along we'll be better at it next time.

Indeed.

> 
> > I can't measure how much would be spent on making C code safer and 
> > how much would be on writing Rust bindings though. If such efforts 
> > would be 80%-90% for making subsystems code safer, it should 
> > worth the efforts even if Rust code ends being removed.
> > 
> > 2) Rust experiment succeeds. In long term it would mean that
> > subsystems should, at some point, stop accepting C code and start
> > using only Rust for new code, and several drivers in C would require
> > conversion to Rust or moved to staging in order to be deprecated.  
> 
> I don't think that's what success looks like.  I think we'd continue in
> dual C/Rust mode almost indefinitely. 

I disagree. The burden of maintaining both C and Rust code on subsystems
will likely force the hand to either switch to Rust or to remove it, as
it will increase with time and with more code porting to Rust or written
in C.

I mean, when new Rust code gets added, specially at subsystem's core, it
may end that some features will only work properly (or would be
thoughtfully tested) in Rust while others would only work properly in C.

So, if enough subsystem's developers got convinced about the advantages
of it, the long road to deprecate C may start happening - at least
subsystem-wide.

Granted, a full conversion will certainly require years or even decades, 
but that's a separate history.

> Look how long it took the kernel to add enough flexibility just to
> compile the existing C with clang.

It looks a lot more, but it wasn't that much of time.

Clang self-hosting started in 2010[1]. So, we're talking of ~12 years of 
since when it started compiling itself. 

During such time frame, Clang got mature enough to become compatible with 
real-world open source code, which probably happened somewhere between
Clang 3.5 (2014) and Clang 4.0 (2017).

[1] See: https://en.wikipedia.org/wiki/Clang

    IMO, before self-hosting, it was more like a compiler experiment, as
    clang wouldn't survive on a gcc-free world.

> There may be a point where we ask should we deprecate C, but that's
> independent of and probably way beyond the point where Rust is a
> success.
> 
> > 3) Some maintainers would consider it a success while others would
> > consider it a failure. That's the worse case scenario. If we reach
> > that, some Kernel/Maintainers Summit hard discussions would likely 
> > be needed, in order to avoid subsystem's fragmentation with regards 
> > to accepting or not C and/or Rust code subsystem-wide.  
> 
> So this is where we have to ask hard questions about what does success
> (or failure) actually look like. I think success is really at least one
> subsystem demonstrates support and enthusiasm for the Rust conversion
> and it doesn't cause a huge drain on those who don't embrace it.

I don't think that having a single subsystem adopting Rust would be enough for
it to be considered a success or a failure. It will very much depend on what
subsystem is, and, most importantly, how the Rust code on it will interact 
with other subsystems that depend on it.

E. g. one thing would be to have a subsystem for a new class of devices
using Rust. People that won't need such devices will barely notice it.
A very different thing would be to have a widely used subsystem
enthusiastically supporting Rust in a proper way.

> That leaves open the door for more converts but doesn't force them.  We 
> can continually evaluate the maintenance burden in this mode and debate
> whether it's too great or is acceptable. 

> I think failure is definitely no subsystem wants to embrace rust.

Agreed: this would be a failure.

> The problem case is where a subsystem embraces rust has issues but
> doesn't want to admit failure because it would lead to the failure of
> the rust project ... this one we'll need to examine in detail.

True. 

Regards,
Mauro