Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation

Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation

[Miguel Ojeda]

On Tue, May 26, 2026 at 1:58 PM Aary Milind Kinge <kingeaary@gmail.com> wrote:
>
> The unconditional 128-byte const array allocation for every unique
> `Devres<T>` caused unnecessary .rodata bloat in production builds,

Wasn't the string deduplicated?

> terminator), the copy routine now appends "..." at the end — copying

Did an LLM assist this patch? If so, please add a tag:

  https://docs.kernel.org/process/generated-content.html
  https://docs.kernel.org/process/coding-assistants.html

Moreover, this should be sent to the right maintainers and reviewers,
e.g. at least to "DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS". Cc'ing
them here, but also please Cc all the "RUST" entry.

> +        let mut buf = [0u8; 128];

Why is there a hardcoded literal? Please use constants where possible,
deriving the rest of the literals from that.

> +        let mut len = 0;
> +        while len < 128 && static_buf[len] != 0 {
> +            len += 1;
> +        }
> +
> +        // SAFETY: `static_buf` is promoted to static memory, and we verified the null byte.

This should explain why this is all OK, e.g. why it doesn't go out of
bounds (a local-only reading of the loop above would appear to make it
so).

Or avoid `unsafe` altogether if possible.

> +    #[cfg(not(CONFIG_DEBUG_DEVRES))]
> +    const TYPE_NAME_CSTR: &'static crate::str::CStr = crate::c_str!("");

Is the name not used at all under `!CONFIG_DEBUG_DEVRES`?

Either way, could we move the other `const`s inside this one, and
remove the `cfg` here? i.e. reducing the number of conditional items
and avoiding to repeat the "signature" of this `const`.

>  // Expected to become stable.
>  #![feature(arbitrary_self_types)]
>  #![feature(derive_coerce_pointee)]
> +#![feature(const_type_name)]

New features need to be justified in the commit message, with a link
to the tracking issue:

  https://github.com/rust-lang/rust/issues/63084

In particular, please justify why you think it will become stable.
Usually, we need to double-check with upstream that is the case.

Thanks!

Cheers,
Miguel

Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation

[David Laight]

On Tue, 26 May 2026 14:37:44 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Tue, May 26, 2026 at 1:58 PM Aary Milind Kinge <kingeaary@gmail.com> wrote:
> >
> > The unconditional 128-byte const array allocation for every unique
> > `Devres<T>` caused unnecessary .rodata bloat in production builds,  
> 
> Wasn't the string deduplicated?
> 
> > terminator), the copy routine now appends "..." at the end — copying  
> 
> Did an LLM assist this patch? If so, please add a tag:
> 
>   https://docs.kernel.org/process/generated-content.html
>   https://docs.kernel.org/process/coding-assistants.html
> 
> Moreover, this should be sent to the right maintainers and reviewers,
> e.g. at least to "DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS". Cc'ing
> them here, but also please Cc all the "RUST" entry.
> 
> > +        let mut buf = [0u8; 128];  
> 
> Why is there a hardcoded literal? Please use constants where possible,
> deriving the rest of the literals from that.
> 
> > +        let mut len = 0;
> > +        while len < 128 && static_buf[len] != 0 {
> > +            len += 1;
> > +        }
> > +
> > +        // SAFETY: `static_buf` is promoted to static memory, and we verified the null byte.  
> 
> This should explain why this is all OK, e.g. why it doesn't go out of
> bounds (a local-only reading of the loop above would appear to make it
> so).

I'm no rust expert (or novice) but that code all looks like run-time
initialisers rather that the static data you really want.

Can you generate the '\0' terminated C 'string' by including an explicit
zero byte in the rust one?

-- David