Rust in our code base

Karol Herbst kherbst at redhat.com
Sat Aug 20 12:22:48 UTC 2022


Hey everybody,

so I think it's time to have this discussion for real.

I am working on Rusticl
(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15439)
which I would like to merge quite soon.

Others might also plan on starting kernel drivers written in Rust (and
if people feel comfortable to discuss this as well, they might reply
here)

The overall implication of that is: if we are doing this, people (that
is we) have to accept that touching Rust code will be part of our
development process. There is no other sane way of doing it.

I am not willing to wrap things in Rusticl so changing gallium APIs
won't involve touching Rust code, and we also can't expect people to
design their kernel drivers in weird ways "just because somebody
doesn't want to deal with Rust"

If we are going to do this, we have to do it for real, which means,
Rust code will call C APIs directly and a change in those APIs will
also require changes in Rust code making use of those APIs.

I am so explicit on this very point, because we had some discussion on
IRC where this was seen as a no-go at least from some people, which
makes me think we have to find a mutual agreement on how it should be
going forward.

And I want to be very explicit here about the future of Rusticl as
well: if the agreement is that people don't want to have to deal with
Rust changing e.g. gallium, Rusticl is a dead project. I am not
willing to come up with some trashy external-internal API just to
maintain Rusticl outside of the mesa git repo.
And doing it on a kernel level is even more of a no-go.

So what are we all thinking about Rust in our core repos?

CCing a bunch of people who think are the most impacted by it either
from a reviewer/maintainer or developer perspective. If you think some
others should be explicitly aware of this, please point them to this
discussion here.

Karol



More information about the dri-devel mailing list