* Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation [not found] ` <20260526115825.1480768-1-kingeaary@gmail.com> @ 2026-05-26 12:37 ` Miguel Ojeda 2026-05-26 15:03 ` David Laight 0 siblings, 1 reply; 2+ messages in thread From: Miguel Ojeda @ 2026-05-26 12:37 UTC (permalink / raw) To: Aary Milind Kinge, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich Cc: Miguel Ojeda, Alice Ryhl, rust-for-linux, linux-kernel, driver-core 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation 2026-05-26 12:37 ` [PATCH v2] rust: devres: optimize type name allocation and fix truncation Miguel Ojeda @ 2026-05-26 15:03 ` David Laight 0 siblings, 0 replies; 2+ messages in thread From: David Laight @ 2026-05-26 15:03 UTC (permalink / raw) To: Miguel Ojeda Cc: Aary Milind Kinge, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Alice Ryhl, rust-for-linux, linux-kernel, driver-core 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-26 15:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260526094329.533943-1-kingeaary@gmail.com>
[not found] ` <20260526115825.1480768-1-kingeaary@gmail.com>
2026-05-26 12:37 ` [PATCH v2] rust: devres: optimize type name allocation and fix truncation Miguel Ojeda
2026-05-26 15:03 ` David Laight
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox