Re: [PATCH v18 0/4] Rust bindings for gem shmem

[Gary Guo]

On Sun Jun 7, 2026 at 3:07 AM BST, Alexandre Courbot wrote:
> On Fri Jun 5, 2026 at 4:24 AM JST, Lyude Paul wrote:
>> Most of this patch series has already been pushed upstream, this is just
>> the second half of the patch series that has not been pushed yet + some
>> additional changes which were required to implement changes requested by
>> the mailing list. This patch series is originally from Asahi, previously
>> posted by Daniel Almeida.
>>
>> The previous version of the patch series can be found here:
>>
>> 	https://patchwork.freedesktop.org/series/164580/
>>
>> Branch with patches applied available here:
>>
>> 	https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem
>>
>> This patch series applies on top of drm-rust-next
>>
>> Patch-series wide changes since V15:
>> * Fix some major rebasing errors I somehow didn't notice :(
>> * Drop the dependency on LazyInit, use the trick that Alice suggested
>>   instead.
>> * Fix dependency ordering so that Tyr can get the vmap stuff first
>>   without the other bits.
>> Patch-series wide changes since V16:
>> * Fix ordering one more time (SetOnce::reset() doesn't need to come
>>   before adding vmap functions)
>> * Rebase against the latest DeviceContext changes from me that got
>>   pushed.
>>
>
> Not a problem of this series, but when trying to build it I initially
> got these warnings/errors:
>
> CLIPPY L rust/kernel.o
> warning: gendwarfksyms: symbol_print_versions: no information for symbol _RNvMs1_NtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninitINtB5_11MaybeUninitINtNtCsbuTvttuFvbr_6kernel6devres6DevresINtNtNtNtB18_3drm3gem5shmem10SGTableMapNtNtB1K_5tests11KunitObjectNtNtB1O_6device6UninitEEE16assume_init_dropB18_

IMO we really shouldn't use Clippy to generate code. We spent too much effort in
fixing codegen issues that are only present when driven by clippy.

We should just run a check phase with clippy to get the lints only, and then use
rustc to generate actual code.

Best,
Gary

> ...
> .vmlinux.export.c:8577:500: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> .vmlinux.export.c:8577:501: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> .vmlinux.export.c:8577:502: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> .vmlinux.export.c:8577:503: warning: null character ignored [-Wnull-character]
>  8577 |   ...<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>...
>       |      ^
> ...
> .vmlinux.export.c:24529:2: error: embedding a #include directive within macro arguments is not supported
>  24529 | #include <linux/module.h>
>        |  ^
> .vmlinux.export.c:8577:1: note: expansion of macro 'KSYMTAB_FUNC' requested here
>  8577 | KSYMTAB_FUNC(_RINvXsi_NtNtCsbuTvttuFvbr_6kernel4sync3arcINtB6_9UniqueArcINtNtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninit11MaybeUninitIN...
>       | ^
> .vmlinux.export.c:8577:1: error: unterminated function-like macro invocation
>  8577 | KSYMTAB_FUNC(_RINvXsi_NtNtCsbuTvttuFvbr_6kernel4sync3arcINtB6_9UniqueArcINtNtNtCsjYlAz7NZ3Sw_4core3mem12maybe_uninit11MaybeUninitIN...
>       | ^
> ../include/linux/export-internal.h:62:9: note: macro 'KSYMTAB_FUNC' defined here
>    62 | #define KSYMTAB_FUNC(name, ns)  __KSYMTAB(name, KSYM_FUNC(name), ns)
>       |         ^
>
> This is fixed by [1]. Maybe we should merge that one patch separately
> and before the rest? I seem to be seeing these long symbol problems more
> often recently.
>
> [1] https://lore.kernel.org/all/20260605-nova-exports-v4-1-e948c287407c@xxxxxxxxxx/