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/[email protected]/
