Re: Writing the Apple AGX GPU driver in Rust?

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

On Fri, Aug 12, 2022 at 6:01 AM Asahi Lina <lina@asahilina.net> wrote:
>
> But this also ties into the question of where the Rust boundary is: even
> if, for some reason, the DRM folks were against Rust bindings entirely,
> I would still want to write parts of my driver in it, even if it means
> calling into them from a smaller DRM C driver, since it would make my
> life much easier as the author/maintainer of this particular driver!

I guess it depends -- for instance, if they would need to understand
what is going on in your other Rust code for some reason (I don't know
if that would be the case here), and they cannot easily follow it
because it is in Rust, then it could still affect them indirectly at
some point, so they could have a reason to oppose it I guess
(personally, I think if everybody is reasonable and willing to learn a
bit, that will not be a problem).

In other words, we would love to see Rust used everywhere (of course)
but we have to be mindful about where/how we introduce it (we are not
even in mainline yet), and be as much in agreement as possible with
maintainers where it may affect them.

> In particular, trying to make a comprehensive DRM binding as a
> prerequisite is a huge task, especially if you want it to cover KMS too.
> DRM isn't a self-contained API surface like most smaller subsystems, but
> rather a large collection of modular components that are intended to be
> reused by drivers. On top of that, KMS is quite complex from a
> programming model standpoint. There's a lot that goes into display drivers!

There is no requirement to create abstractions for everything of a
particular subsystem (sorry if that was unclear), i.e. what I
understood from your previous message is that the subset you need
(e.g. the render portion of DRM) would be feasible to tackle. Is that
correct? (i.e. I am referring to the first approach you mentioned)

> Of course, it would be great to move towards a world with more Rust! I'm
> just trying to be practical and not bite off more than I can chew right
> off the bat. I do hope that if I can do this in Rust, that might help
> the Rust-for-Linux project along the way and maybe encourage other folks
> to try writing new drivers to Rust (or rewrite existing ones).

Yes, definitely! In fact, I am confident a lot of people would love to
see Rust used in such a "big driver", and it would be a key driver to
showcase what is possible (this is what I meant when I said if you
happened to write a subset of the DRM abstractions, then others could
follow your lead later on).

> That's why I went with the proc macro approach, which lets me write the
> code once and keep it looking like normal Rust code with something that
> looks similar to #[cfg()] conditionals, except then it magically becomes
> many code variants in a single compilation step, without involving the
> build system (more than it already is for proc macros). If I were doing
> this in C, the only reasonable way I can think of doing it would be
> #ifdefs and multiple compilation of the same files with different
> defines (or multiple #includes into one compilation unit...).

It is probably a good idea to check with those sending the MiBs of
generated code, in case it is a policy.

> Thanks, I just joined!

My pleasure!

> By the way, just a minor thing: I noticed that all the rust-for-linux
> code seems to be GPL-2.0. Was this an explicit decision, or just a
> default? The DRM core is dual-licensed GPL/MIT, as are some of the major
> drivers (i915/radeon/amdgpu at least), and this allows OpenBSD to also
> use this code directly. I'd definitely want to use the same approach for
> this driver, since I want it to be useful for other kernels too. So I
> wonder if it might make sense to license some of the Rust core (in
> particular, proc macros and common code written in Rust) more
> permissively, so it can be directly pulled in if other projects want to
> reuse some of the drivers that depend on it.
>
> I think the subsystem bindings matter less here, since those are
> naturally very Linux-specific, except for DRM of course, so this is
> mostly about common scaffolding code.
>
> (It's probably a good time to think about this if it hasn't come up in
> the past, since changing the license after it's upstream would be a lot
> harder!)

We discussed it soon after starting and everyone involved agreed to
use GPL-2.0 everywhere. There was also some discussion about a year
ago about reusing a file for GRUB modules written in Rust.

I can raise this point in Kangrejos/LPC to see what is everyone's
position on it.

Cheers,
Miguel