`nova-drm` is scheduled to expose a user-space API to receive IOCTLs
from user-mode drivers, and to call into `nova-core` to perform the
actual work. We are about to reach the state where we need the ability
to call into `nova-core`, but the current Rust build system does not
support this, and the solution will likely take at least a couple of
cycles to be merged.

In the meantime, this series introduces a Nova-local workaround for
`nova-drm` to call into `nova-core`. It generates the `nova-core`
metadata that `nova-drm` can use to resolve references at build-time,
and also builds a list of exported symbols for symbol resolution when
modules are loaded.

Since Rust symbols are long, this work ran into the limits on symbol
sizes `modpost` can handle. Thus, the first patch instructs the compiler
to inline initializers for some Rust basic types to avoid those long
symbol names when symbols from `nova-core` are exported. Interestingly,
this also results in a smaller nova-core binary size [1].

The rest of the patches enable inter-module calls from nova-drm to
nova-core.

This series is based on `drm-rust-next`.

[1] https://lore.kernel.org/all/DIN76NTFEU1N.1RT6G4IFD62RG@nvidia.com/

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Changes in v3:
- Drop the modpost overflow detection patch as it is to be merged
  through the KBuild tree.
- Drop obsolete (and actually unnecessary) changes to `pin_init`.
- Do not inline methods returning `impl PinInit` as they cannot
  contribute to the long symbol names problem.
- Use `#[inline]` instead of `#[inline(always)]` for methods that could
  create excessively long symbols.
- Link to v2: https://patch.msgid.link/20260527-nova-exports-v2-0-06de4c556d55@nvidia.com

Changes in v2:
- Rebase on top of HRT v5.
- Inline some `pin_init` and Rust basic types methods to avoid long
  symbol names and optimize code.
- Print truncating modpost symbols and abort upon meeting them.
- Drop increase of `buf_printf`'s buffer.
- Drop obsolete nova-core renaming patch.
- Link to v1: https://patch.msgid.link/20260430-nova-exports-v1-0-7ca31664e983@nvidia.com

---
Alexandre Courbot (5):
      rust: inline some init methods
      gpu: nova-core: export Rust symbols for dependent modules
      gpu: nova-core: emit Rust metadata for dependent modules
      gpu: drm: nova: build after nova-core metadata
      [POC] drm: nova: demonstrate interaction with nova-core

 drivers/gpu/drm/nova/Makefile             | 15 ++++++++
 drivers/gpu/drm/nova/driver.rs            |  9 ++++-
 drivers/gpu/nova-core/Makefile            | 48 ++++++++++++++++++++++++-
 drivers/gpu/nova-core/driver.rs           | 59 +++++++++++++++++++++++--------
 drivers/gpu/nova-core/gpu.rs              |  9 +++--
 drivers/gpu/nova-core/nova_core.rs        |  4 +--
 drivers/gpu/nova-core/nova_core_exports.c | 13 +++++++
 rust/kernel/alloc/kbox.rs                 |  2 ++
 rust/kernel/init.rs                       |  1 +
 rust/kernel/sync/arc.rs                   |  2 ++
 10 files changed, 141 insertions(+), 21 deletions(-)
---
base-commit: 0e42ec83d46ab8877d38d37493328ed7d1a24de8
change-id: 20260430-nova-exports-502f996c5aab

Best regards,
--  
Alexandre Courbot <acourbot@nvidia.com>

On Fri, May 29, 2026 at 5:28 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> In the meantime, this series introduces a Nova-local workaround for
> `nova-drm` to call into `nova-core`. It generates the `nova-core`
> metadata that `nova-drm` can use to resolve references at build-time,
> and also builds a list of exported symbols for symbol resolution when
> modules are loaded.

The "local approach" is essentially what I suggested back then, so if
this works for you then I am happy -- with the understanding that we
will replace it with the global support soon (it is good to have a use
case in-tree :)

I see you play some tricks to get the ordering right, including a
sub-make with a double build of the `.rmeta` in "private", which in
turn forces you also to do the `.o`, right?

What I originally had in mind was simply to do everything from a
single parent `Makefile` instead, precisely to avoid complexity (after
all, it is the local approach, so you don't need to force yourself to
handle that). That should remove all those shenanigans, and it is way
easier to get right. Did you consider it?

By the way, I think a `.gitignore` entry for the generated header is missing.

Cheers,
Miguel

> On Fri, May 29, 2026 at 5:28 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> In the meantime, this series introduces a Nova-local workaround for
>> `nova-drm` to call into `nova-core`. It generates the `nova-core`
>> metadata that `nova-drm` can use to resolve references at build-time,
>> and also builds a list of exported symbols for symbol resolution when
>> modules are loaded.
>
> The "local approach" is essentially what I suggested back then, so if
> this works for you then I am happy -- with the understanding that we
> will replace it with the global support soon (it is good to have a use
> case in-tree :)

Yup, I just want to have something that allows us to call from
`nova-drm` to `nova-core` as it becomes increasingly pressing for us to
be able to do so, but will be very happy to replace this with the global
support as soon as it is available.

This patchset won't make it for the 7.2 merge window, so if support in
the R4L build system comes during the next cycle we may even be able to
skip this altogether.

>
> I see you play some tricks to get the ordering right, including a
> sub-make with a double build of the `.rmeta` in "private", which in
> turn forces you also to do the `.o`, right?
>
> What I originally had in mind was simply to do everything from a
> single parent `Makefile` instead, precisely to avoid complexity (after
> all, it is the local approach, so you don't need to force yourself to
> handle that). That should remove all those shenanigans, and it is way
> easier to get right. Did you consider it?

I haven't thought about that, no - in that case the parent `Makefile`
would need to be the one in `drivers`? Or am I missing something?

>
> By the way, I think a `.gitignore` entry for the generated header is missing.

Thanks, I'll add that.

On Wed, Jun 3, 2026 at 12:30 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> Yup, I just want to have something that allows us to call from
> `nova-drm` to `nova-core` as it becomes increasingly pressing for us to
> be able to do so, but will be very happy to replace this with the global
> support as soon as it is available.
>
> This patchset won't make it for the 7.2 merge window, so if support in
> the R4L build system comes during the next cycle we may even be able to
> skip this altogether.

Sounds good.

> I haven't thought about that, no - in that case the parent `Makefile`
> would need to be the one in `drivers`? Or am I missing something?

I think `drivers/gpu/` should also work. Maybe it works inside a
deeper one, but I don't recall trying that.

So essentially you can move both `nova-drm` and `nova-core` (and the
exports of course) there, and then since everything is in a single
`Makefile`, we can just add the dependency between them as a standard
Make one.

I think you don't even need their old `Makefile`s anymore, and that
avoids the double building and so on and so forth. You still need to
emit the metadata, but I think we can pass the flag, avoiding the
custom rule too.

Cheers,
Miguel

On Mon, Jun 1, 2026 at 3:50 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> By the way, I think a `.gitignore` entry for the generated header is missing.

A few other notes:

  - The `exports` rule' `awk` filtering is stricter than the one we
normally use -- it is fine if you don't need `static`s etc., but I
will likely export `T|R|D|B` when I replace it, not just `T`.

  - Similarly, you don't use `EXPORT_SYMBOL_RUST_GPL` and the "dummy
symbol" is a function instead of the simple `int`. Is there a reason
for that? i.e. the ones you want to export are functions, but using
the global one (even defining `EXPORT_SYMBOL_RUST_GPL` the same way)
would reduce the divergence (so one less thing to think about later
when I replace it).

  - I noticed touching `nova-core` and then running a build twice will
only build `nova-drm.ko` the second time -- you may want to use
`--extern nova_core -L $(objtree)/...` like we do in `rust/Makefile`
instead of giving an explicit path to `--extern`.

I hope that helps!

Cheers,
Miguel

On Tue Jun 2, 2026 at 2:00 AM JST, Miguel Ojeda wrote:
> On Mon, Jun 1, 2026 at 3:50 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>>
>> By the way, I think a `.gitignore` entry for the generated header is missing.
>
> A few other notes:
>
>   - The `exports` rule' `awk` filtering is stricter than the one we
> normally use -- it is fine if you don't need `static`s etc., but I
> will likely export `T|R|D|B` when I replace it, not just `T`.

If I include all 4 (I tried to align more with `rust/Makefile`), then I
get the following warnings:

WARNING: modpost: drivers/gpu/nova-core: _RNvNtNtCs6PUMngfe6Jo_9nova_core13___module_init13___module_init37___UNIQUE_ID___addressable_init_module: EXPORT_SYMBOL used for init symbol. Remove __init or EXPORT_SYMBOL.
WARNING: modpost: drivers/gpu/nova-core: _RNvNtNtCs6PUMngfe6Jo_9nova_core13___module_init13___module_init40___UNIQUE_ID___addressable_cleanup_module: EXPORT_SYMBOL used for exit symbol. Remove __exit or EXPORT_SYMBOL.

So I've added an extra filter and it seems to work now.

>   - Similarly, you don't use `EXPORT_SYMBOL_RUST_GPL` and the "dummy
> symbol" is a function instead of the simple `int`. Is there a reason
> for that? i.e. the ones you want to export are functions, but using
> the global one (even defining `EXPORT_SYMBOL_RUST_GPL` the same way)
> would reduce the divergence (so one less thing to think about later
> when I replace it).

No reason in particular. Here as well I have tried to align with
`rust/Makefile`.

>
>   - I noticed touching `nova-core` and then running a build twice will
> only build `nova-drm.ko` the second time -- you may want to use
> `--extern nova_core -L $(objtree)/...` like we do in `rust/Makefile`
> instead of giving an explicit path to `--extern`.

Yes, getting the order right is a bit difficult. Moving everything under
`drivers/gpu/Makefile` solves this, thankfully.