[Mesa-dev] Rust drivers in Mesa

[Jason Ekstrand]

On Fri, Oct 2, 2020 at 5:51 PM <timur.kristof at gmail.com> wrote:
>
> On Fri, 2020-10-02 at 12:53 -0500, Jason Ekstrand wrote:
> > On Fri, Oct 2, 2020 at 11:34 AM Eric Anholt <eric at anholt.net> wrote:
> > > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> > > <alyssa.rosenzweig at collabora.com> wrote:
> > > > Hi all,
> > > >
> > > > Recently I've been thinking about the potential for the Rust
> > > > programming
> > > > language in Mesa. Rust bills itself a safe system programming
> > > > language
> > > > with comparable performance to C [0], which is a naturally fit
> > > > for
> > > > graphics driver development.
> > > >
> >
> > [...]
> >
> > That said, I really do like Rust as a language.  I'm not sure I'd go
> > quite as far as Anholt but I feel like it has everything I like about
> > C++ without most of what I dislike.  I'm not sure how we would do
> > things like ANV's GenXML multi-compile magic but I'm sure we could
> > figure out a way.  I'd love to see someone build something in Rust
> > and
> > figure out some best practices.
> >
> > --Jason
>
> The good thing about C++ is that you can pick a subset of features that
> you like, and stick to them. Then you'll never have to deal with other
> the stuff if you don't want to. There exists a subset of the language
> which helps get rid of most memory management issues.

The difficulty in Mesa has always been deciding what that subset is.
This thread is proof of that.  So far we've had people extole
everything from basic type safety and memory management to template
meta-programming.  Features which one developer enjoys another
loathes.  This is why we tend to stick to C for the core: It's limited
but those limitations we can sort-of all agree on it.

> I would also argue that there exist a bunch of tools that can help make
> C/C++ code stay safe, for example our collegaue Tony has recently
> addressed some findings by an undefined behaviour sanitizer. There are
> also free and open source static analyzers.
>
> I like the idea of Rust, especially their intention to focus on safety,
> but honestly, I don't like how they realized it.
>
> The Rust syntax is slightly annoying. They departed from C/C++ enough
> to make Rust look different, but then they got lazy and for some reason
> they chose to keep the most annoying parts from C/C++ like curly braces
> and semicolons, so even if we switch to Rust we can still enjoy
> debating important topics like where to put curly braces, how many
> spaces or tabs are best, and so on.

IMO: Like many modern languages, Rust has a defined default coding
style and It's pretty reasonable.  We should just go with it.

> My main concern is that memory is just one of many resources that we
> need to use safely, but it's the only one that Rust concerns itself
> with. Memory safety can give you a false sense of security. It's
> possible to write insecure apps that are perfectly memory safe.
>
> That said, I think it's perfectly okay to give it a try, write a
> backend compiler in Rust and see what happens. However, I don't think
> it is feasible or desireable to rewrite complicated parts from C/C++ to
> Rust. I think Daniel Steinberg's thoughts apply:
> https://daniel.haxx.se/blog/2017/03/27/curl-is-c/

Same.  Different developers/teams make different choices in their
drivers and back-ends all the time.  Some use C++ while others stickk
to C.  They all have different coding styles and choose different C++
feature sets (when they use C++).  IMO, the choice to use a language
like Rust is no different.  As long as it doesn't cause a giant
project-wide problem, I'm fine with it.

Even bits in core like the SPIR-V parser, if all the developers who
are working in that area want to write it in Rust, I'd say it's ok.  I
doubt it will actually happen because, has has been pointed out, those
bits of the code base are all large and aging and rewriting the SPIR-V
parser, as much as it might be fun from a "make it more secure"
perspective, would likely introduce far more bugs in the short term
than it would solve long-term.

--Jason