On Wed May 20, 2026 at 3:44 AM BST, Alexandre Courbot wrote: > Hi Gary, > > On Fri May 1, 2026 at 10:02 PM JST, Gary Guo wrote: >> 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. > > Do you mean we should use `KSYM_NAME_LEN` for the size of `tmp`? The > formatted strings can be longer than the symbol name alone (see the > example below which wraps it into `KSYMTAB_FUNC()`), so this should > probably be `KSYM_NAME_LEN + something` if we align to it. > >> >> 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. > > Here is an example string that doesn't make it, it doesn't seem related > to doctests but also doesn't occur on all configs: > > ERROR: modpost: buf_printf output was truncated for string > KSYMTAB_FUNC(_RINvXs5_NtNtCs1EKtwoKEMO2_6kernel5alloc4kboxINtB6_3BoxINtNtNtCs1peUGmbrgHn_4core3mem12maybe_uninit11MaybeUninitINtNtBa_9auxiliary16RegistrationDataNtNtCs6wA3Ay79aUn_9nova_core6driver7AuxDataEENtNtB8_9allocator7KmallocEINtCsfxcgfq7FLKi_8pin_init12InPlaceWriteB1L_E14write_pin_initNtNtBa_5error5ErrorINtNtB3x_10___internal11InitClosureNCINvYIBH_B1L_B34_EINtNtBa_4init11InPlaceInitB1L_E8pin_initB4t_IB4N_NCINvMsd_B1O_INtB1O_12RegistrationINtNtNtBa_5types6for_lt15UnsafeForLtImplDG_INtB72_:
`InPlaceWrite` should definitely be inline as you pointed out in the reply. I have some pin_init symbol length opt planned as well. It also looks like this has to do with the fact that the type being generated with `ForLt` macro being overly complex. Perhaps `define_for_lt!` is a better approach. Best, Gary > 608 bytes needed, 500 available
