On Wed Aug 12, 2026 at 10:53 PM BST, Danilo Krummrich wrote:
> (Cc: Mark)
>
> On Wed Aug 12, 2026 at 6:33 PM CEST, Miguel Ojeda wrote:
>> On Tue, Aug 11, 2026 at 8:41 AM Alvin Sun <[email protected]> wrote:
>>>
>>> The series moves `THIS_MODULE` into the `ModuleMetadata` as a const,
>>> threads it
>>> through `#[vtable]` to set `fops.owner` in DRM/miscdevice, and updates
>>> configfs
>>> and rnull to use `this_module::<LocalModule>()`.
>>
>> Applied to `rust-next` -- thanks everyone!
>
> This series has a semantic conflict with both the driver-core and the drm-rust
> tree:
>
> @Mark: When you merge driver-core-next after rust-next (which I think is the
> case) then you need to include the diff in [1] into the merge.
>
> In drm-rust-next the build fails with:
>
> error[E0425]: cannot find type `LocalModule` in the crate root
> --> rust/kernel/drm/gem/shmem.rs:628:5
> |
> 628 | #[vtable]
> | ^^^^^^^^^ not found in the crate root
> |
> = note: this error originates in the attribute macro `vtable` (in
> Nightly builds, run with -Z macro-backtrace for more info)
>
> which is because the kunit test in rust/kernel/drm/gem/shmem.rs uses the
> #[vtable] macro.
>
> This should be fixed up with a patch on top of this series in rust-next.
>
> I came up with to potential solutions [2] and [3]. I think with the new build
> system we want [3], but I'm not entirely sure this works correctly with the
> current build system in all cases (at least it did survive my tests).
>
> Alternatively, we could just open-code a dummy module as in [2] for now.
>
> [1] driver-core-next merge fixup
>
> diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
> index a4927452016e..17ca504b7f8d 100644
> --- a/rust/kernel/serdev.rs
> +++ b/rust/kernel/serdev.rs
> @@ -87,7 +87,7 @@ unsafe fn register(
> }
>
> // SAFETY: `sdrv` is guaranteed to be a valid `DriverType`.
> - to_result(unsafe {
> bindings::__serdev_device_driver_register(sdrv.get(), module.0) })
> + to_result(unsafe {
> bindings::__serdev_device_driver_register(sdrv.get(), module.as_ptr()) })
`module.0` shouldn't be used in the first place, it just happens to be visible
due to the unfortunate placement at crate root.
Perhaps you can update driver-core tree to use `as_ptr()`? It was already there
and not newly introduced in the series.
> }
>
> unsafe fn unregister(sdrv: &Opaque<Self::DriverType>) {
>
> [2] Open-coded dummy module
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index c04e6c5aa7e0..274924cfcc05 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -157,6 +157,15 @@
> /// Prefix to appear before log messages printed from within the `kernel`
> crate.
> const __LOG_PREFIX: &[u8] = b"rust_kernel\0";
>
> +/// Dummy module type for `#[vtable]` impl blocks within the kernel crate
> (e.g. kunit tests).
> +struct LocalModule;
> +
> +impl ModuleMetadata for LocalModule {
> + const NAME: &'static str::CStr = c"rust_kernel";
> + // SAFETY: `try_module_get`/`module_put` handle null module pointers
> gracefully.
> + const THIS_MODULE: ThisModule = unsafe {
> ThisModule::from_ptr(core::ptr::null_mut()) };
> +}
> +
> #[cfg(not(testlib))]
> #[panic_handler]
> fn panic(info: &core::panic::PanicInfo<'_>) -> ! {
IMO this is the correct way, also consistent with
https://lore.kernel.org/rust-for-linux/[email protected]/
It might make sense to add this to rust-next.
Best,
Gary
