Re: [TECH TOPIC] Rust for Linux

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Miguel,

On Tue, Jul 06, 2021 at 08:29:21PM +0200, Miguel Ojeda wrote:
> On Tue, Jul 6, 2021 at 5:43 PM Laurent Pinchart wrote:
> >
> > There are lots of core APIs that are used by most drivers and that are
> > not subsystem-specific, so those will need to be considered too.
> 
> Yes, but those are maintained in the "common"/shared support, e.g.
> data structures, sync-related facilities, etc.; and hopefully will be
> much better understood by everyone.
> 
> > Additionally, even if there's a subsystem maintainer willing to maintain
> > a Rust abstraction, it also means that someone doing tree-wide or
> > subsystem-wide refactoring will need to pull the maintainer(s) in and
> > make it a team project. I really don't see how that can scale, tree-wide
> > changes are already very painful.
> >
> > I'm afraid that doesn't really match how development is done today :-)
> > Lots of subsystem-wide refactoring is done by developers who are not
> > subsystem maintainers.
> 
> What I was saying is that the changes need to go through the
> maintainers, which then would know Rust and the abstractions they
> maintain.
> 
> Of course, somebody wishing to do tree-wide refactoring needs to know
> at least a bit of Rust to at least know how to refactor and submit the
> code for the maintainers -- but that is a given.
> 
> After all, if we are going to have Rust as a second language in the
> kernel, we should try to have as many people on board as possible, at
> least to some degree, within some reasonable time frame.

I agree with you here, it's a honest way to look at it: adopting Rust as
a second language in the kernel isn't just a technical decision with
limited impact, but also a process decision that will create a
requirement for most kernel developers to learn Rust. Whether that
should and will happen is what we're debating, but regardless of the
outcome, it's important to phrase the question correctly, with a broad
view of the implications.

(That being said, there are also lots of technical challenges of course)

-- 
Regards,

Laurent Pinchart