[PATCH 0/7] gpu: drm: nova: enable calling into nova-core

[PATCH 0/7] gpu: drm: nova: enable calling into nova-core

[Alexandre Courbot]

`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
currently support this, and the solution will likely take at least a
couple of cycles to be merged.

In the meantime, this series would like to introduce 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 of `modpost`,
which the first two patches try to address: the first one, by detecting
and reporting buffer overflow situations that were ignored until now;
the second, by increasing the size of the buffer used to build the
symbol names, so `nova-core`'s symbols can fit.

@Miguel: I expect the design used here will allow us to smoothly switch
to the new build system once it is merged; I hope you are ok with this
temporary workaround.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Alexandre Courbot (7):
      scripts: modpost: detect and report truncated buf_printf() output
      scripts: modpost: increase buf_printf's buffer size
      gpu: nova-core: rename module from nova_core to nova-core
      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            |  6 ++++
 drivers/gpu/nova-core/Kconfig             |  2 +-
 drivers/gpu/nova-core/Makefile            | 48 ++++++++++++++++++++++++++++++-
 drivers/gpu/nova-core/driver.rs           | 20 +++++++++++--
 drivers/gpu/nova-core/gpu.rs              |  9 ++++--
 drivers/gpu/nova-core/nova_core.rs        |  4 +--
 drivers/gpu/nova-core/nova_core_exports.c | 11 +++++++
 scripts/mod/modpost.c                     | 13 +++++++--
 9 files changed, 117 insertions(+), 11 deletions(-)
---
base-commit: 11a63a5335eb7b5da4ca38014fa83be5d437144d
change-id: 20260430-nova-exports-502f996c5aab

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

[PATCH 1/7] scripts: modpost: detect and report truncated buf_printf() output

[Alexandre Courbot]

buf_printf() uses a fixed-size stack buffer. vsnprintf() returns the
number of bytes that *would* have been written to that buffer, which can
be larger than the size of said buffer if the formatted string is too
long.

The problem is that whenever this happens buf_printf() currently passes
this length, unchecked, to buf_write(), which silently reads past the
stack buffer and copies invalid data into the output buffer.

Fix this by detecting vsnprintf() failures and truncations before
appending to the output buffer, and report a fatal error instead of
producing corrupt symbol names.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 scripts/mod/modpost.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index abbcd3fc1394..16f6bc20b058 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1689,8 +1689,17 @@ void __attribute__((format(printf, 2, 3))) buf_printf(struct buffer *buf,
 
 	va_start(ap, fmt);
 	len = vsnprintf(tmp, SZ, fmt, ap);
-	buf_write(buf, tmp, len);
 	va_end(ap);
+
+	if (len < 0) {
+		perror("vsnprintf failed");
+		exit(1);
+	}
+	if (len >= SZ)
+		fatal("buf_printf output was truncated: %d bytes needed, %d available\n",
+		      len + 1, SZ);
+
+	buf_write(buf, tmp, len);
 }
 
 void buf_write(struct buffer *buf, const char *s, int len)

-- 
2.54.0

[PATCH 2/7] scripts: modpost: increase buf_printf's buffer size

[Alexandre Courbot]

Rust tends to produce long symbol names; when trying to export symbols
from nova-core for nova-drm to link to, the 500 bytes of the internal
buffer used for symbol name formatting are not enough, making modpost
fail.

Fix this by increasing the size of the buffer used to format the symbols
to 1024 bytes. It is a stack buffer, but modpost is a user-space program
so that shouldn't be a problem.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 scripts/mod/modpost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 16f6bc20b058..2ab7aa6edcb4 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1674,7 +1674,7 @@ static void read_symbols_from_files(const char *filename)
 	fclose(in);
 }
 
-#define SZ 500
+#define SZ 1024
 
 /* We first write the generated file into memory using the
  * following helper, then compare to the file on disk and

-- 
2.54.0

[PATCH 3/7] gpu: nova-core: rename module from nova_core to nova-core

[Alexandre Courbot]

Rename the kbuild module target from `nova_core.o` to `nova-core.o`.
This avoids a name collision between the module target and the Rust
crate object (`nova_core.o` from `nova_core.rs`), allowing the driver to
be built as a composite module.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drivers/gpu/nova-core/Kconfig  | 2 +-
 drivers/gpu/nova-core/Makefile | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
index d8456f8eaa05..f918f69e0599 100644
--- a/drivers/gpu/nova-core/Kconfig
+++ b/drivers/gpu/nova-core/Kconfig
@@ -14,4 +14,4 @@ config NOVA_CORE
 
 	  This driver is work in progress and may not be functional.
 
-	  If M is selected, the module will be called nova_core.
+	  If M is selected, the module will be called nova-core.
diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
index 2d78c50126e1..1f794baadc86 100644
--- a/drivers/gpu/nova-core/Makefile
+++ b/drivers/gpu/nova-core/Makefile
@@ -1,3 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_NOVA_CORE) += nova_core.o
+obj-$(CONFIG_NOVA_CORE) += nova-core.o
+
+nova-core-y := nova_core.o

-- 
2.54.0

[PATCH 4/7] gpu: nova-core: export Rust symbols for dependent modules

[Alexandre Courbot]

Export `nova-core`'s Rust symbols so that other loadable modules,
particularly `nova-drm`, can resolve references to `nova-core` at
runtime.

This is done by generating declarations and `EXPORT_SYMBOL_GPL()` calls
for Rust global text symbols using `nm` and compiling them into the
module as `nova_core_exports.o`.

This is a workaround until the build system supports Rust cross-crate
dependencies natively.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drivers/gpu/nova-core/Makefile            | 22 +++++++++++++++++++++-
 drivers/gpu/nova-core/nova_core_exports.c | 11 +++++++++++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
index 1f794baadc86..f9aaf19f2477 100644
--- a/drivers/gpu/nova-core/Makefile
+++ b/drivers/gpu/nova-core/Makefile
@@ -2,4 +2,24 @@
 
 obj-$(CONFIG_NOVA_CORE) += nova-core.o
 
-nova-core-y := nova_core.o
+nova-core-y := nova_core.o nova_core_exports.o
+
+# Export Rust symbols so dependent modules can use them at runtime.
+#
+# This is a workaround until the build system supports Rust cross-module
+# dependencies natively.
+# Kbuild uses Rust v0 mangling, whose symbols start with "_R".
+rust_exports = \
+	$(NM) -p --defined-only $(1) | \
+	awk '$$2 == "T" && $$3 ~ /^_R/ { \
+		printf "extern void %s(void); EXPORT_SYMBOL_GPL(%s);\n", $$3, $$3 \
+	}'
+
+define filechk_nova_core_exports
+	$(call rust_exports,$(obj)/nova_core.o)
+endef
+
+$(obj)/exports_nova_core_generated.h: $(obj)/nova_core.o FORCE
+	$(call filechk,nova_core_exports)
+
+$(obj)/nova_core_exports.o: $(obj)/exports_nova_core_generated.h
diff --git a/drivers/gpu/nova-core/nova_core_exports.c b/drivers/gpu/nova-core/nova_core_exports.c
new file mode 100644
index 000000000000..1d3f1544fe8d
--- /dev/null
+++ b/drivers/gpu/nova-core/nova_core_exports.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Exports Rust symbols from the `nova_core` crate for use by dependent modules.
+ *
+ * This is a workaround until the build system supports Rust cross-module
+ * dependencies natively.
+ */
+
+#include <linux/export.h>
+
+#include "exports_nova_core_generated.h"

-- 
2.54.0

[PATCH 5/7] gpu: nova-core: emit Rust metadata for dependent modules

[Alexandre Courbot]

Emit nova-core's `.rmeta` crate metadata so dependent Rust modules can
resolve nova-core's types and functions via `--extern`.

The metadata is exposed as an explicit Kbuild target instead of relying
on an untracked side effect of the object build. This lets dependent
modules ask for the metadata directly, including single-target builds
where `nova-core`'s object may already be up to date.

This is a workaround until the build system supports Rust cross-crate
dependencies natively.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drivers/gpu/nova-core/Makefile | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
index f9aaf19f2477..fea6d5c68cd6 100644
--- a/drivers/gpu/nova-core/Makefile
+++ b/drivers/gpu/nova-core/Makefile
@@ -23,3 +23,27 @@ $(obj)/exports_nova_core_generated.h: $(obj)/nova_core.o FORCE
 	$(call filechk,nova_core_exports)
 
 $(obj)/nova_core_exports.o: $(obj)/exports_nova_core_generated.h
+
+# Dependent Rust drivers need `nova-core`'s crate metadata.
+# Expose it as an explicit target so they can request it directly.
+nova_core_rmeta := libnova_core.rmeta
+nova_core_rmeta_private := .nova_core_rmeta/$(nova_core_rmeta)
+targets += $(nova_core_rmeta) $(nova_core_rmeta_private)
+
+# Build in a private directory to avoid racing with `nova_core.o` on rustc's
+# intermediate object names during parallel builds.
+quiet_cmd_rustc_rmeta_rs = RUSTC RMETA $@
+      cmd_rustc_rmeta_rs = mkdir -p $(dir $@); \
+		$(rust_common_cmd) --emit=metadata=$@ \
+		--emit=obj=$(basename $@).o $<; \
+		rm -f $(basename $@).o
+
+$(obj)/$(nova_core_rmeta_private): private __modname := nova-core
+$(obj)/$(nova_core_rmeta_private): private part-of-builtin := $(if $(filter y,$(CONFIG_NOVA_CORE)),y)
+$(obj)/$(nova_core_rmeta_private): private part-of-module := $(if $(filter m,$(CONFIG_NOVA_CORE)),y)
+$(obj)/$(nova_core_rmeta_private): $(obj)/nova_core.rs FORCE
+	+$(call if_changed_dep,rustc_rmeta_rs)
+
+# Keep the metadata available at a stable path for consumers.
+$(obj)/$(nova_core_rmeta): $(obj)/$(nova_core_rmeta_private) FORCE
+	$(call if_changed,copy)

-- 
2.54.0

[PATCH 6/7] gpu: drm: nova: build after nova-core metadata

[Alexandre Courbot]

Point rustc to `nova-core`'s `.rmeta` file so `nova-drm` can use
`nova_core`'s types and functions at compile time.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drivers/gpu/drm/nova/Makefile | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/nova/Makefile b/drivers/gpu/drm/nova/Makefile
index 42019bff3173..f1d59c65120f 100644
--- a/drivers/gpu/drm/nova/Makefile
+++ b/drivers/gpu/drm/nova/Makefile
@@ -1,3 +1,18 @@
 # SPDX-License-Identifier: GPL-2.0
 
+nova_core_rmeta := drivers/gpu/nova-core/libnova_core.rmeta
+
+rustflags-y += --extern nova_core=$(objtree)/$(nova_core_rmeta)
+
+# `nova-drm` imports `nova-core` at compile time, so request `nova-core`'s
+# explicit metadata target before compiling nova.o.
+$(obj)/nova.o: | $(objtree)/$(nova_core_rmeta)
+
+# Build `nova-core`'s metadata by invoking make.
+#
+# This is ugly but only temporary until the build system natively supports
+# cross-crate dependencies.
+$(objtree)/$(nova_core_rmeta): FORCE
+	$(Q)$(MAKE) $(build)=drivers/gpu/nova-core $(nova_core_rmeta)
+
 obj-$(CONFIG_DRM_NOVA) += nova.o

-- 
2.54.0

[PATCH POC 7/7] drm: nova: demonstrate interaction with nova-core

[Alexandre Courbot]

Export a few items from nova-core and use them from nova-drm in order to
print the chipset of the GPU being probed.

Some documentation items are added to make Clippy happy.

This is only meant for demonstration purposes, and won't be merged.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drivers/gpu/drm/nova/driver.rs     |  6 ++++++
 drivers/gpu/nova-core/driver.rs    | 20 ++++++++++++++++++--
 drivers/gpu/nova-core/gpu.rs       |  9 ++++++---
 drivers/gpu/nova-core/nova_core.rs |  4 ++--
 4 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
index b1af0a099551..e18e9fccc067 100644
--- a/drivers/gpu/drm/nova/driver.rs
+++ b/drivers/gpu/drm/nova/driver.rs
@@ -15,6 +15,8 @@
 use crate::file::File;
 use crate::gem::NovaObject;
 
+use nova_core::driver::NovaCore;
+
 pub(crate) struct NovaDriver {
     #[expect(unused)]
     drm: ARef<drm::Device<Self>>,
@@ -54,6 +56,10 @@ impl auxiliary::Driver for NovaDriver {
     const ID_TABLE: auxiliary::IdTable<Self::IdInfo> = &AUX_TABLE;
 
     fn probe(adev: &auxiliary::Device<Core>, _info: &Self::IdInfo) -> impl PinInit<Self, Error> {
+        let chipset = NovaCore::chipset(adev)?;
+
+        pr_info!("Chipset from nova-core: {}\n", chipset);
+
         let data = try_pin_init!(NovaData { adev: adev.into() });
 
         let drm = drm::Device::<Self>::new(adev.as_ref(), data)?;
diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 84b0e1703150..985f65e13bd5 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
+//! Main driver module.
+
 use kernel::{
     auxiliary,
     device::Core,
@@ -23,13 +25,17 @@
     },
 };
 
-use crate::gpu::Gpu;
+use crate::gpu::{
+    self,
+    Gpu, //
+};
 
 /// Counter for generating unique auxiliary device IDs.
 static AUXILIARY_ID_COUNTER: Atomic<u32> = Atomic::new(0);
 
+/// Driver-associated data.
 #[pin_data]
-pub(crate) struct NovaCore {
+pub struct NovaCore {
     #[pin]
     pub(crate) gpu: Gpu,
     #[pin]
@@ -112,3 +118,13 @@ fn unbind(pdev: &pci::Device<Core>, this: Pin<&Self>) {
         this.gpu.unbind(pdev.as_ref());
     }
 }
+
+impl NovaCore {
+    /// Returns the chipset of this GPU.
+    pub fn chipset(adev: &auxiliary::Device<Core>) -> Result<gpu::Chipset> {
+        let dev = adev.parent();
+        let drvdata = dev.drvdata::<Self>()?;
+
+        Ok(drvdata.gpu.spec.chipset)
+    }
+}
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 659f6a24ee13..75190ca0693b 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
+//! Declares some core driver types.
+
 use kernel::{
     device,
     devres::Devres,
@@ -31,7 +33,8 @@ macro_rules! define_chipset {
     {
         /// Enum representation of the GPU chipset.
         #[derive(fmt::Debug, Copy, Clone, PartialOrd, Ord, PartialEq, Eq)]
-        pub(crate) enum Chipset {
+        #[allow(missing_docs)]
+        pub enum Chipset {
             $($variant = $value),*,
         }
 
@@ -185,7 +188,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
 /// Structure holding a basic description of the GPU: `Chipset` and `Revision`.
 #[derive(Clone, Copy)]
 pub(crate) struct Spec {
-    chipset: Chipset,
+    pub(crate) chipset: Chipset,
     revision: Revision,
 }
 
@@ -247,7 +250,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
 /// Structure holding the resources required to operate the GPU.
 #[pin_data]
 pub(crate) struct Gpu {
-    spec: Spec,
+    pub(crate) spec: Spec,
     /// MMIO mapping of PCI BAR 0
     bar: Arc<Devres<Bar0>>,
     /// System memory page required for flushing all pending GPU-side memory writes done through
diff --git a/drivers/gpu/nova-core/nova_core.rs b/drivers/gpu/nova-core/nova_core.rs
index 3a609f6937e4..ccb98c73457b 100644
--- a/drivers/gpu/nova-core/nova_core.rs
+++ b/drivers/gpu/nova-core/nova_core.rs
@@ -13,11 +13,11 @@
 #[macro_use]
 mod bitfield;
 
-mod driver;
+pub mod driver;
 mod falcon;
 mod fb;
 mod firmware;
-mod gpu;
+pub mod gpu;
 mod gsp;
 #[macro_use]
 mod num;

-- 
2.54.0

Re: [PATCH 3/7] gpu: nova-core: rename module from nova_core to nova-core

[Joel Fernandes]

On 4/30/2026 10:55 AM, Alexandre Courbot wrote:
> Rename the kbuild module target from `nova_core.o` to `nova-core.o`.
> This avoids a name collision between the module target and the Rust
> crate object (`nova_core.o` from `nova_core.rs`), allowing the driver to
> be built as a composite module.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>  drivers/gpu/nova-core/Kconfig  | 2 +-
>  drivers/gpu/nova-core/Makefile | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
> index d8456f8eaa05..f918f69e0599 100644
> --- a/drivers/gpu/nova-core/Kconfig
> +++ b/drivers/gpu/nova-core/Kconfig
> @@ -14,4 +14,4 @@ config NOVA_CORE
>  
>  	  This driver is work in progress and may not be functional.
>  
> -	  If M is selected, the module will be called nova_core.
> +	  If M is selected, the module will be called nova-core.
> diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
> index 2d78c50126e1..1f794baadc86 100644
> --- a/drivers/gpu/nova-core/Makefile
> +++ b/drivers/gpu/nova-core/Makefile
> @@ -1,3 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -obj-$(CONFIG_NOVA_CORE) += nova_core.o
> +obj-$(CONFIG_NOVA_CORE) += nova-core.o

I think a more descriptive name would be better than relying on dashes versus
versus underscores, that's super confusing, how about:

> +
> +nova-core-y := nova_core.o
> 

Lets make this: `nova-core-y := nova-core-mod.o`?

thanks,

--
Joel fernandes

Re: [PATCH 4/7] gpu: nova-core: export Rust symbols for dependent modules

[Joel Fernandes]

Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
One comment below:

On 4/30/2026 10:55 AM, Alexandre Courbot wrote:
> Export `nova-core`'s Rust symbols so that other loadable modules,
> particularly `nova-drm`, can resolve references to `nova-core` at
> runtime.
> 
> This is done by generating declarations and `EXPORT_SYMBOL_GPL()` calls
> for Rust global text symbols using `nm` and compiling them into the
> module as `nova_core_exports.o`.
> 
> This is a workaround until the build system supports Rust cross-crate
> dependencies natively.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>  drivers/gpu/nova-core/Makefile            | 22 +++++++++++++++++++++-
>  drivers/gpu/nova-core/nova_core_exports.c | 11 +++++++++++
>  2 files changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
> index 1f794baadc86..f9aaf19f2477 100644
> --- a/drivers/gpu/nova-core/Makefile
> +++ b/drivers/gpu/nova-core/Makefile
> @@ -2,4 +2,24 @@
>  
>  obj-$(CONFIG_NOVA_CORE) += nova-core.o
>  
> -nova-core-y := nova_core.o
> +nova-core-y := nova_core.o nova_core_exports.o
> +
> +# Export Rust symbols so dependent modules can use them at runtime.
> +#
> +# This is a workaround until the build system supports Rust cross-module
> +# dependencies natively.
> +# Kbuild uses Rust v0 mangling, whose symbols start with "_R".
> +rust_exports = \
> +	$(NM) -p --defined-only $(1) | \
> +	awk '$$2 == "T" && $$3 ~ /^_R/ { \
> +		printf "extern void %s(void); EXPORT_SYMBOL_GPL(%s);\n", $$3, $$3 \
> +	}'

I am curious (in a fun way) how this (Or Miguel's later approach) will work with
generics. I don't think we have such use cases but suppose a module has a
function foo<T> which is expected to be called externally outside the module.
Suppose the module itself does not call foo internally.

How does the rust compiler know that this function can be called externally if
it resolves to no callers within the translation unit?

Further, as a result, how does the above extern get emitted then if foo never
ended up in the object?

Probably Miguel's future infrastructure will address this? If so, probably the
limitation of the above approach should be called out in the code comments and
commit message.

thanks,

--
Joel Fernandes

> +
> +define filechk_nova_core_exports
> +	$(call rust_exports,$(obj)/nova_core.o)
> +endef
> +
> +$(obj)/exports_nova_core_generated.h: $(obj)/nova_core.o FORCE
> +	$(call filechk,nova_core_exports)
> +
> +$(obj)/nova_core_exports.o: $(obj)/exports_nova_core_generated.h
> diff --git a/drivers/gpu/nova-core/nova_core_exports.c b/drivers/gpu/nova-core/nova_core_exports.c
> new file mode 100644
> index 000000000000..1d3f1544fe8d
> --- /dev/null
> +++ b/drivers/gpu/nova-core/nova_core_exports.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Exports Rust symbols from the `nova_core` crate for use by dependent modules.
> + *
> + * This is a workaround until the build system supports Rust cross-module
> + * dependencies natively.
> + */
> +
> +#include <linux/export.h>
> +
> +#include "exports_nova_core_generated.h"
> 


I
-- 
Joel Fernandes

Re: [PATCH 3/7] gpu: nova-core: rename module from nova_core to nova-core

[Alexandre Courbot]

On Fri May 1, 2026 at 12:07 AM JST, Joel Fernandes wrote:
> On 4/30/2026 10:55 AM, Alexandre Courbot wrote:
>> Rename the kbuild module target from `nova_core.o` to `nova-core.o`.
>> This avoids a name collision between the module target and the Rust
>> crate object (`nova_core.o` from `nova_core.rs`), allowing the driver to
>> be built as a composite module.
>> 
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>>  drivers/gpu/nova-core/Kconfig  | 2 +-
>>  drivers/gpu/nova-core/Makefile | 4 +++-
>>  2 files changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
>> index d8456f8eaa05..f918f69e0599 100644
>> --- a/drivers/gpu/nova-core/Kconfig
>> +++ b/drivers/gpu/nova-core/Kconfig
>> @@ -14,4 +14,4 @@ config NOVA_CORE
>>  
>>  	  This driver is work in progress and may not be functional.
>>  
>> -	  If M is selected, the module will be called nova_core.
>> +	  If M is selected, the module will be called nova-core.
>> diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
>> index 2d78c50126e1..1f794baadc86 100644
>> --- a/drivers/gpu/nova-core/Makefile
>> +++ b/drivers/gpu/nova-core/Makefile
>> @@ -1,3 +1,5 @@
>>  # SPDX-License-Identifier: GPL-2.0
>>  
>> -obj-$(CONFIG_NOVA_CORE) += nova_core.o
>> +obj-$(CONFIG_NOVA_CORE) += nova-core.o
>
> I think a more descriptive name would be better than relying on dashes versus
> versus underscores, that's super confusing, how about:
>
>> +
>> +nova-core-y := nova_core.o
>> 
>
> Lets make this: `nova-core-y := nova-core-mod.o`?

We would have to rename `nova_core.rs` to `nova_core_mod.rs` though.

But your argument has a point generally speaking - if there wasn't
any underscore in the module's name, then we would have to pick a
different name anyway.

Another option would be to use the Rust-idiomatic `lib.rs`. That's what
the kernel crate and others do.

Danilo, WDYT?

Re: [PATCH 4/7] gpu: nova-core: export Rust symbols for dependent modules

[Alexandre Courbot]

On Fri May 1, 2026 at 12:22 AM JST, Joel Fernandes wrote:
>
> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
> One comment below:
>
> On 4/30/2026 10:55 AM, Alexandre Courbot wrote:
>> Export `nova-core`'s Rust symbols so that other loadable modules,
>> particularly `nova-drm`, can resolve references to `nova-core` at
>> runtime.
>> 
>> This is done by generating declarations and `EXPORT_SYMBOL_GPL()` calls
>> for Rust global text symbols using `nm` and compiling them into the
>> module as `nova_core_exports.o`.
>> 
>> This is a workaround until the build system supports Rust cross-crate
>> dependencies natively.
>> 
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>>  drivers/gpu/nova-core/Makefile            | 22 +++++++++++++++++++++-
>>  drivers/gpu/nova-core/nova_core_exports.c | 11 +++++++++++
>>  2 files changed, 32 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/nova-core/Makefile b/drivers/gpu/nova-core/Makefile
>> index 1f794baadc86..f9aaf19f2477 100644
>> --- a/drivers/gpu/nova-core/Makefile
>> +++ b/drivers/gpu/nova-core/Makefile
>> @@ -2,4 +2,24 @@
>>  
>>  obj-$(CONFIG_NOVA_CORE) += nova-core.o
>>  
>> -nova-core-y := nova_core.o
>> +nova-core-y := nova_core.o nova_core_exports.o
>> +
>> +# Export Rust symbols so dependent modules can use them at runtime.
>> +#
>> +# This is a workaround until the build system supports Rust cross-module
>> +# dependencies natively.
>> +# Kbuild uses Rust v0 mangling, whose symbols start with "_R".
>> +rust_exports = \
>> +	$(NM) -p --defined-only $(1) | \
>> +	awk '$$2 == "T" && $$3 ~ /^_R/ { \
>> +		printf "extern void %s(void); EXPORT_SYMBOL_GPL(%s);\n", $$3, $$3 \
>> +	}'
>
> I am curious (in a fun way) how this (Or Miguel's later approach) will work with
> generics. I don't think we have such use cases but suppose a module has a
> function foo<T> which is expected to be called externally outside the module.
> Suppose the module itself does not call foo internally.
>
> How does the rust compiler know that this function can be called externally if
> it resolves to no callers within the translation unit?
>
> Further, as a result, how does the above extern get emitted then if foo never
> ended up in the object?
>
> Probably Miguel's future infrastructure will address this? If so, probably the
> limitation of the above approach should be called out in the code comments and
> commit message.

Short version: it should Just Work (c). The next patch of the series
generates the metadata of the `nova-core` crate, which contains the MIR
representation of all generic elements. If `nova-drm` needs to
monomorphize some generic code, it will do it from that representation -
thus an export of the symbol is not needed.

IIUC this is how inter-crate generics are handled in Rust, so this is
also the way the kernel is also expected to do.

Re: [PATCH 4/7] gpu: nova-core: export Rust symbols for dependent modules

[Miguel Ojeda]

On Thu, Apr 30, 2026 at 5:22 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> How does the rust compiler know that this function can be called externally if
> it resolves to no callers within the translation unit?

Like Alex mentions, that information is what the `.rmeta` files
contain, which are generated by the compiler and consumed by the
compiler later on.

They contain stuff like generics that you point out, in order to
actually use them later on, as well as many other things.

In a way, you can think of them as opaque, generated "C headers" with
all the information needed to build later crates. Other languages take
similar approaches.

Cheers,
Miguel

Re: [PATCH 3/7] gpu: nova-core: rename module from nova_core to nova-core

[John Hubbard]

On 5/1/26 5:25 AM, Alexandre Courbot wrote:
> On Fri May 1, 2026 at 12:07 AM JST, Joel Fernandes wrote:
>> On 4/30/2026 10:55 AM, Alexandre Courbot wrote:
...
>> Lets make this: `nova-core-y := nova-core-mod.o`?
> 
> We would have to rename `nova_core.rs` to `nova_core_mod.rs` though.
> 
> But your argument has a point generally speaking - if there wasn't
> any underscore in the module's name, then we would have to pick a
> different name anyway.
> 
> Another option would be to use the Rust-idiomatic `lib.rs`. That's what
> the kernel crate and others do.

"lib" (or something like that) is better, because we will want to avoid 
"mod" in the name. There is plenty of "mod" naming floating around
already, due to how kbuild names its artifacts, so adding more "mod"
will not increase our happiness. :)

$ ls -a | grep mod | grep nova
nova_core.mod
nova_core.mod.c
.nova_core.mod.cmd
nova_core.mod.o
.nova_core.mod.o.cmd

thanks,
-- 
John Hubbard

Re: [PATCH 3/7] gpu: nova-core: rename module from nova_core to nova-core

[Danilo Krummrich]

On Fri May 1, 2026 at 5:25 AM CEST, Alexandre Courbot wrote:
> Danilo, WDYT?

I think the patch is fine as is.

However, the commit message should say that it also changes nova_core.ko to
nova-core.ko, which is the reason I proposed this in [1] as well.

I.e. such that the module name (that we still need to change; I can send a patch
since I haven't heard back from Chou) matches the .ko file name.

I'm not a fan of generic names like lib.rs, mod.rs, main.rs, etc., as it messes
with fuzzy finder tools.

If people feel strongly about this, we can probably rename it to
nova_core_main.rs, but I think it is not necessary.

- Danilo

[1] https://lore.kernel.org/all/DH56PG8GLW4X.2QMHJ91J9D29N@kernel.org/

Re: [PATCH 2/7] scripts: modpost: increase buf_printf's buffer size

[Gary Guo]

On Thu Apr 30, 2026 at 3:55 PM BST, Alexandre Courbot wrote:
> Rust tends to produce long symbol names; when trying to export symbols
> from nova-core for nova-drm to link to, the 500 bytes of the internal
> buffer used for symbol name formatting are not enough, making modpost
> fail.
>
> Fix this by increasing the size of the buffer used to format the symbols
> to 1024 bytes. It is a stack buffer, but modpost is a user-space program
> so that shouldn't be a problem.

I think we should make sure all constants related to symbol names match.
KSYM_NAME_LEN is 512 so this should just be that.

The only case that I've been hit with very long symbol names so far is doc tests.
Can you provide an example of the case where you're hit with very long symbol
names in Nova? In many cases they're just functions that are supposed to be
inlined but isn't.

Best,
Gary

>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>  scripts/mod/modpost.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 16f6bc20b058..2ab7aa6edcb4 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1674,7 +1674,7 @@ static void read_symbols_from_files(const char *filename)
>  	fclose(in);
>  }
>  
> -#define SZ 500
> +#define SZ 1024
>  
>  /* We first write the generated file into memory using the
>   * following helper, then compare to the file on disk and

Re: [PATCH 2/7] scripts: modpost: increase buf_printf's buffer size

[Miguel Ojeda]

On Fri, May 1, 2026 at 3:02 PM Gary Guo <gary@garyguo.net> wrote:
>
> The only case that I've been hit with very long symbol names so far is doc tests.

Yeah, nowadays where I have seen them are doctests too, in particular
for UML debug builds.

Cheers,
Miguel