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

From: Miguel Ojeda

Date: Tue May 26 2026 - 08:38:49 EST


On Tue, May 26, 2026 at 1:58 PM Aary Milind Kinge <kingeaary@xxxxxxxxx> 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