Re: Writing the Apple AGX GPU driver in Rust?

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Sat, Aug 13, 2022 at 5:06 PM Asahi Lina <lina@asahilina.net> wrote:
>
> I think the main issue there is that refactoring that changes the C API
> also has to change the abstractions, so if the people making those
> changes don't want to touch Rust... how would that work out? Refactoring
> patches couldn't be submitted if they break the Rust side.
>
> (Of course, ideally people aren't scared of Rust and simply make the
> changes themselves!)

That is the conundrum, indeed. And yeah, I would think if people is
reasonable, it will eventually work out.

Given Rust is supposed to be introduced in an experimental capacity,
changing the Rust side shouldn't be seen as "scary" (initially at
least), in that if somebody breaks it by mistake, it can always be
fixed, even if takes a bit longer. I think that would encourage others
to do the changes by themselves.

An orthogonal idea could be relaxing the "do not break callers" rule a
bit for Rust, so that it is possible to temporarily break the Rust
side on purpose if there is a good reason to do so (e.g. if a change
really cannot wait for the Rust side to be fixed), especially early in
a cycle.

But yeah, this topic is still ongoing.

> That's good to know! A lot of the APIs have pretty long function lists,
> of which you only end up using a subset for any given driver.

Yeah, precisely -- I hope that makes it way more enticing for you!
(see also below on the unsafe abstractions).

> Cool! Do you know where these branches are being developed? I didn't see
> them in the main Rust-for-Linux tree yet.

I am aware where some of it is, but please contact them directly if
possible (I can help with that) -- they can give you their latest
updates.

> By unsafe APIs you mean abstractions to make the API more idiomatic
> Rust, without necessarily enforcing all invariants (and therefore marked
> unsafe), right? I think I can work with that, if so! It would definitely
> be very useful to start to document the preconditions as part of it (the
> C kernel documentation is often quite terrible at this...).

Exactly, I am referring to having `unsafe fn` functions and methods
which may just require the caller to "do the right thing" (also unsafe
traits etc.). The invariants that you require would still be enforced
-- by the caller.

And, precisely, documenting the preconditions for those helps a lot to
come up later with safe abstractions. In fact, at times you will
likely realize how you will want the safe abstraction to be while
doing it.

After all, making safe abstractions is all about reducing as much as
possible the amount of times we require something from users. And to
do that, one needs to know what we are actually requiring from clients
to begin with.

> That's odd, I've never heard of dual-licensing being an issue in the
> kernel. Lots of drivers are dual licensed, as is the DRM core as I

I see Greg has got involved with details about this (thanks!), so I
defer to him...

Cheers,
Miguel