Re: Writing the Apple AGX GPU driver in Rust?

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

On Thu, Aug 11, 2022 at 4:29 PM Asahi Lina <lina@asahilina.net> wrote:
>
> I'd like to hear your thoughts about how crazy an idea this is. ^_^

It is less crazy than writing it in Python, for sure ;)

But joking aside, using Rust for a particular subsystem is up to the
maintainers of the subsystem. From what I understand (please correct
me if I am wrong!), you are part of the Asahi team, so you are your
own maintainers, thus it is up to you to decide!

Now, of course, reality is more complex than that, and you will
probably want to discuss things with the DRM people to see if they
would be willing to accept and/or maintain their part of the Rust
bindings you may need etc.

In any case, one quick note: so far, we have been doing the "Rust
driver that talks to Rust safe abstractions that for the most part
wrap existing C facilities" approach. While it is of course
technically possible to mix C and Rust in other ways, and it may be
the case that we need to do it as some point, it would be best to
avoid having to expose C APIs from Rust code, to avoid losing the
advantages of the type system. So writing the entire driver in Rust
would be the way to go if I understood you correctly, and would make
also things much easier for others later too, since some safe
abstractions for DRM would be there already etc., which I am sure
people will appreciate a lot in the future!

As for the proc macros: so far we generally try to avoid them as much
as possible, but a lot of details on how we will expand on that are
still in the air (and we have not needed to generate a lot of
hardware-description-based code anyway). Some of that will likely be
discussed in Kangrejos and LPC in September. In any case, when talking
about proc macros, it can be useful to consider whether "raw" code
generation in an independent build step may be easier or not (i.e.
like your previous Python approach, if I understood correctly; but
maybe based on a Rust host program which we have support for) --
especially if that code does not change often.

(I sent you the Zulip invitation soon after seeing your message -- if
you have not received it, let me know!)

Cheers,
Miguel