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

[David Laight <david.laight.linux@gmail.com>]

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