* [PATCH] rust: seq_file: route seq_print! directly to seq_write
@ 2026-05-14 5:37 Donjuanplatinum
2026-05-14 7:04 ` Greg KH
2026-05-16 4:08 ` [PATCH v2] " Yifei Yao
0 siblings, 2 replies; 6+ messages in thread
From: Donjuanplatinum @ 2026-05-14 5:37 UTC (permalink / raw)
To: ojeda, viro, brauner
Cc: boqun, gary, bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross,
dakr, jack, rust-for-linux, linux-fsdevel, linux-kernel,
Donjuanplatinum
Currently, the `seq_print!` macro formats output by passing a Rust
`fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
This involves crossing the FFI boundary, parsing the
format string in C via `vsnprintf`, and triggering a callback back
into Rust to perform the actual buffer write.
This patch implements `core::fmt::Write` for `&SeqFile` and updates
`call_printf` to use it, routing Rust's formatting directly to
`bindings::seq_write`. This approach leverages the bounded string
slices naturally produced by the Rust formatting machinery and copies
them directly into the `seq_file` buffer.
By mapping to `seq_write`, we bypass the C string parsing state machine
and the `%pA` FFI callback, streamlining the execution path. Since
`seq_write` uses a bounded `memcpy` relying on the explicitly passed
length, it perfectly matches Rust's `&str` semantics and operates
safely without requiring null-termination.
Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
If an overflow occurs during a partial write, `seq_write` sets the
overflow flag. The `seq_file` subsystem inherently handles this by
discarding the current record and retrying with a larger buffer.
Therefore, this optimization introduces no observable semantic change
to user-space.
Signed-off-by: Donjuanplatinum <donplat@barrensea.org>
---
rust/kernel/seq_file.rs | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/rust/kernel/seq_file.rs b/rust/kernel/seq_file.rs
index 518265558..16ba1fdd8 100644
--- a/rust/kernel/seq_file.rs
+++ b/rust/kernel/seq_file.rs
@@ -4,7 +4,7 @@
//!
//! C header: [`include/linux/seq_file.h`](srctree/include/linux/seq_file.h)
-use crate::{bindings, fmt, str::CStrExt as _, types::NotThreadSafe, types::Opaque};
+use crate::{bindings, ffi::c_void, fmt, types::NotThreadSafe, types::Opaque};
/// A utility for generating the contents of a seq file.
#[repr(transparent)]
@@ -32,14 +32,26 @@ pub unsafe fn from_raw<'a>(ptr: *mut bindings::seq_file) -> &'a SeqFile {
/// Used by the [`seq_print`] macro.
#[inline]
pub fn call_printf(&self, args: fmt::Arguments<'_>) {
- // SAFETY: Passing a void pointer to `Arguments` is valid for `%pA`.
+ let mut this = self;
+ let _ = fmt::Write::write_fmt(&mut this, args);
+ }
+}
+
+impl fmt::Write for &SeqFile {
+ fn write_str(&mut self, s: &str) -> fmt::Result {
+ // SAFETY: `self` is a valid reference, ensuring `self.inner.get()` is a valid pointer
+ // to `struct seq_file`. `s` is a valid string slice, guaranteeing `s.as_ptr()` is
+ // readable for `s.len()` bytes. `seq_write` handles bounds checking and does not
+ // require a null-terminated string.
+ //
+ // CAST: `s.as_ptr()` (a `*const u8`) is cast to `*const c_void` because `seq_write`
+ // only reads the buffer via `memcpy` and does not care about the underlying type.
+
unsafe {
- bindings::seq_printf(
- self.inner.get(),
- c"%pA".as_char_ptr(),
- core::ptr::from_ref(&args).cast::<crate::ffi::c_void>(),
- );
+ bindings::seq_write(self.inner.get(), s.as_ptr().cast::<c_void>(), s.len());
}
+
+ Ok(())
}
}
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] rust: seq_file: route seq_print! directly to seq_write
2026-05-14 5:37 [PATCH] rust: seq_file: route seq_print! directly to seq_write Donjuanplatinum
@ 2026-05-14 7:04 ` Greg KH
2026-05-16 4:08 ` [PATCH v2] " Yifei Yao
1 sibling, 0 replies; 6+ messages in thread
From: Greg KH @ 2026-05-14 7:04 UTC (permalink / raw)
To: Donjuanplatinum
Cc: ojeda, viro, brauner, boqun, gary, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, dakr, jack, rust-for-linux, linux-fsdevel,
linux-kernel
On Thu, May 14, 2026 at 01:37:24PM +0800, Donjuanplatinum wrote:
> Currently, the `seq_print!` macro formats output by passing a Rust
> `fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
> This involves crossing the FFI boundary, parsing the
> format string in C via `vsnprintf`, and triggering a callback back
> into Rust to perform the actual buffer write.
>
> This patch implements `core::fmt::Write` for `&SeqFile` and updates
> `call_printf` to use it, routing Rust's formatting directly to
> `bindings::seq_write`. This approach leverages the bounded string
> slices naturally produced by the Rust formatting machinery and copies
> them directly into the `seq_file` buffer.
>
> By mapping to `seq_write`, we bypass the C string parsing state machine
> and the `%pA` FFI callback, streamlining the execution path. Since
> `seq_write` uses a bounded `memcpy` relying on the explicitly passed
> length, it perfectly matches Rust's `&str` semantics and operates
> safely without requiring null-termination.
>
> Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
> If an overflow occurs during a partial write, `seq_write` sets the
> overflow flag. The `seq_file` subsystem inherently handles this by
> discarding the current record and retrying with a larger buffer.
> Therefore, this optimization introduces no observable semantic change
> to user-space.
>
> Signed-off-by: Donjuanplatinum <donplat@barrensea.org>
> ---
> rust/kernel/seq_file.rs | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/rust/kernel/seq_file.rs b/rust/kernel/seq_file.rs
> index 518265558..16ba1fdd8 100644
> --- a/rust/kernel/seq_file.rs
> +++ b/rust/kernel/seq_file.rs
> @@ -4,7 +4,7 @@
> //!
> //! C header: [`include/linux/seq_file.h`](srctree/include/linux/seq_file.h)
>
> -use crate::{bindings, fmt, str::CStrExt as _, types::NotThreadSafe, types::Opaque};
> +use crate::{bindings, ffi::c_void, fmt, types::NotThreadSafe, types::Opaque};
>
> /// A utility for generating the contents of a seq file.
> #[repr(transparent)]
> @@ -32,14 +32,26 @@ pub unsafe fn from_raw<'a>(ptr: *mut bindings::seq_file) -> &'a SeqFile {
> /// Used by the [`seq_print`] macro.
> #[inline]
> pub fn call_printf(&self, args: fmt::Arguments<'_>) {
> - // SAFETY: Passing a void pointer to `Arguments` is valid for `%pA`.
> + let mut this = self;
> + let _ = fmt::Write::write_fmt(&mut this, args);
> + }
> +}
> +
> +impl fmt::Write for &SeqFile {
> + fn write_str(&mut self, s: &str) -> fmt::Result {
> + // SAFETY: `self` is a valid reference, ensuring `self.inner.get()` is a valid pointer
> + // to `struct seq_file`. `s` is a valid string slice, guaranteeing `s.as_ptr()` is
> + // readable for `s.len()` bytes. `seq_write` handles bounds checking and does not
> + // require a null-terminated string.
> + //
> + // CAST: `s.as_ptr()` (a `*const u8`) is cast to `*const c_void` because `seq_write`
> + // only reads the buffer via `memcpy` and does not care about the underlying type.
> +
> unsafe {
> - bindings::seq_printf(
> - self.inner.get(),
> - c"%pA".as_char_ptr(),
> - core::ptr::from_ref(&args).cast::<crate::ffi::c_void>(),
> - );
> + bindings::seq_write(self.inner.get(), s.as_ptr().cast::<c_void>(), s.len());
> }
> +
> + Ok(())
> }
> }
>
> --
> 2.53.0
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- It looks like you did not use your "real" name for the patch on either
the Signed-off-by: line, or the From: line (both of which have to
match). Please read the kernel file,
Documentation/process/submitting-patches.rst for how to do this
correctly.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] rust: seq_file: route seq_print! directly to seq_write
2026-05-14 5:37 [PATCH] rust: seq_file: route seq_print! directly to seq_write Donjuanplatinum
2026-05-14 7:04 ` Greg KH
@ 2026-05-16 4:08 ` Yifei Yao
2026-05-16 7:57 ` Onur Özkan
2026-05-16 19:34 ` Gary Guo
1 sibling, 2 replies; 6+ messages in thread
From: Yifei Yao @ 2026-05-16 4:08 UTC (permalink / raw)
To: donplat
Cc: a.hindborg, aliceryhl, bjorn3_gh, boqun, brauner, dakr, gary,
jack, linux-fsdevel, linux-kernel, lossin, ojeda, rust-for-linux,
tmgross, viro
Currently, the `seq_print!` macro formats output by passing a Rust
`fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
This involves crossing the FFI boundary, parsing the
format string in C via `vsnprintf`, and triggering a callback back
into Rust to perform the actual buffer write.
This patch implements `core::fmt::Write` for `&SeqFile` and updates
`call_printf` to use it, routing Rust's formatting directly to
`bindings::seq_write`. This approach leverages the bounded string
slices naturally produced by the Rust formatting machinery and copies
them directly into the `seq_file` buffer.
By mapping to `seq_write`, we bypass the C string parsing state machine
and the `%pA` FFI callback, streamlining the execution path. Since
`seq_write` uses a bounded `memcpy` relying on the explicitly passed
length, it perfectly matches Rust's `&str` semantics and operates
safely without requiring null-termination.
Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
If an overflow occurs during a partial write, `seq_write` sets the
overflow flag. The `seq_file` subsystem inherently handles this by
discarding the current record and retrying with a larger buffer.
Therefore, this optimization introduces no observable semantic change
to user-space.
Signed-off-by: Yifei Yao <donplat@barrensea.org>
---
Changes in v2:
- Add `#[inline]` annotation to the `write_str` trait method.
- Fix author name and signed-off name to use real name per the kernel's
DCO policy.
- Correctly check the return value of `seq_write` and propagates errors on overflow.
rust/kernel/seq_file.rs | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/rust/kernel/seq_file.rs b/rust/kernel/seq_file.rs
index 518265558d6..d7dbdadde60 100644
--- a/rust/kernel/seq_file.rs
+++ b/rust/kernel/seq_file.rs
@@ -4,7 +4,7 @@
//!
//! C header: [`include/linux/seq_file.h`](srctree/include/linux/seq_file.h)
-use crate::{bindings, fmt, str::CStrExt as _, types::NotThreadSafe, types::Opaque};
+use crate::{bindings, ffi::c_void, fmt, types::NotThreadSafe, types::Opaque};
/// A utility for generating the contents of a seq file.
#[repr(transparent)]
@@ -32,13 +32,29 @@ pub unsafe fn from_raw<'a>(ptr: *mut bindings::seq_file) -> &'a SeqFile {
/// Used by the [`seq_print`] macro.
#[inline]
pub fn call_printf(&self, args: fmt::Arguments<'_>) {
- // SAFETY: Passing a void pointer to `Arguments` is valid for `%pA`.
- unsafe {
- bindings::seq_printf(
- self.inner.get(),
- c"%pA".as_char_ptr(),
- core::ptr::from_ref(&args).cast::<crate::ffi::c_void>(),
- );
+ let mut this = self;
+ let _ = fmt::Write::write_fmt(&mut this, args);
+ }
+}
+
+impl fmt::Write for &SeqFile {
+ #[inline]
+ fn write_str(&mut self, s: &str) -> fmt::Result {
+ // SAFETY: `self` is a valid reference, ensuring `self.inner.get()` is a valid pointer
+ // to `struct seq_file`. `s` is a valid string slice, guaranteeing `s.as_ptr()` is
+ // readable for `s.len()` bytes. `seq_write` handles bounds checking and does not
+ // require a null-terminated string.
+ //
+ // CAST: `s.as_ptr()` (a `*const u8`) is cast to `*const c_void` because `seq_write`
+ // only reads the buffer via `memcpy` and does not care about the underlying type.
+
+ let res =
+ unsafe { bindings::seq_write(self.inner.get(), s.as_ptr().cast::<c_void>(), s.len()) };
+
+ if res < 0 {
+ Err(fmt::Error)
+ } else {
+ Ok(())
}
}
}
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] rust: seq_file: route seq_print! directly to seq_write
2026-05-16 4:08 ` [PATCH v2] " Yifei Yao
@ 2026-05-16 7:57 ` Onur Özkan
2026-05-16 8:21 ` donplat
2026-05-16 19:34 ` Gary Guo
1 sibling, 1 reply; 6+ messages in thread
From: Onur Özkan @ 2026-05-16 7:57 UTC (permalink / raw)
To: Yifei Yao
Cc: a.hindborg, aliceryhl, bjorn3_gh, boqun, brauner, dakr, gary,
jack, linux-fsdevel, linux-kernel, lossin, ojeda, rust-for-linux,
tmgross, viro
On Sat, 16 May 2026 12:08:12 +0800
Yifei Yao <donplat@barrensea.org> wrote:
> Currently, the `seq_print!` macro formats output by passing a Rust
> `fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
> This involves crossing the FFI boundary, parsing the
> format string in C via `vsnprintf`, and triggering a callback back
> into Rust to perform the actual buffer write.
>
> This patch implements `core::fmt::Write` for `&SeqFile` and updates
> `call_printf` to use it, routing Rust's formatting directly to
> `bindings::seq_write`. This approach leverages the bounded string
> slices naturally produced by the Rust formatting machinery and copies
> them directly into the `seq_file` buffer.
>
> By mapping to `seq_write`, we bypass the C string parsing state machine
> and the `%pA` FFI callback, streamlining the execution path. Since
> `seq_write` uses a bounded `memcpy` relying on the explicitly passed
> length, it perfectly matches Rust's `&str` semantics and operates
> safely without requiring null-termination.
>
> Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
> If an overflow occurs during a partial write, `seq_write` sets the
> overflow flag. The `seq_file` subsystem inherently handles this by
> discarding the current record and retrying with a larger buffer.
> Therefore, this optimization introduces no observable semantic change
> to user-space.
>
> Signed-off-by: Yifei Yao <donplat@barrensea.org>
> ---
>
> Changes in v2:
> - Add `#[inline]` annotation to the `write_str` trait method.
> - Fix author name and signed-off name to use real name per the kernel's
> DCO policy.
> - Correctly check the return value of `seq_write` and propagates errors on overflow.
>
> rust/kernel/seq_file.rs | 32 ++++++++++++++++++++++++--------
> 1 file changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/rust/kernel/seq_file.rs b/rust/kernel/seq_file.rs
> index 518265558d6..d7dbdadde60 100644
> --- a/rust/kernel/seq_file.rs
> +++ b/rust/kernel/seq_file.rs
> @@ -4,7 +4,7 @@
> //!
> //! C header: [`include/linux/seq_file.h`](srctree/include/linux/seq_file.h)
>
> -use crate::{bindings, fmt, str::CStrExt as _, types::NotThreadSafe, types::Opaque};
> +use crate::{bindings, ffi::c_void, fmt, types::NotThreadSafe, types::Opaque};
>
> /// A utility for generating the contents of a seq file.
> #[repr(transparent)]
> @@ -32,13 +32,29 @@ pub unsafe fn from_raw<'a>(ptr: *mut bindings::seq_file) -> &'a SeqFile {
> /// Used by the [`seq_print`] macro.
> #[inline]
> pub fn call_printf(&self, args: fmt::Arguments<'_>) {
> - // SAFETY: Passing a void pointer to `Arguments` is valid for `%pA`.
> - unsafe {
> - bindings::seq_printf(
> - self.inner.get(),
> - c"%pA".as_char_ptr(),
> - core::ptr::from_ref(&args).cast::<crate::ffi::c_void>(),
> - );
> + let mut this = self;
> + let _ = fmt::Write::write_fmt(&mut this, args);
> + }
> +}
> +
> +impl fmt::Write for &SeqFile {
> + #[inline]
> + fn write_str(&mut self, s: &str) -> fmt::Result {
> + // SAFETY: `self` is a valid reference, ensuring `self.inner.get()` is a valid pointer
> + // to `struct seq_file`. `s` is a valid string slice, guaranteeing `s.as_ptr()` is
> + // readable for `s.len()` bytes. `seq_write` handles bounds checking and does not
> + // require a null-terminated string.
> + //
> + // CAST: `s.as_ptr()` (a `*const u8`) is cast to `*const c_void` because `seq_write`
> + // only reads the buffer via `memcpy` and does not care about the underlying type.
> +
> + let res =
> + unsafe { bindings::seq_write(self.inner.get(), s.as_ptr().cast::<c_void>(), s.len()) };
> +
> + if res < 0 {
> + Err(fmt::Error)
> + } else {
> + Ok(())
> }
> }
> }
> --
> 2.53.0
>
FYI new versions are usually sent separately.
Onur
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] rust: seq_file: route seq_print! directly to seq_write
2026-05-16 7:57 ` Onur Özkan
@ 2026-05-16 8:21 ` donplat
0 siblings, 0 replies; 6+ messages in thread
From: donplat @ 2026-05-16 8:21 UTC (permalink / raw)
To: Onur Özkan
Cc: a.hindborg, aliceryhl, bjorn3_gh, boqun, brauner, dakr, gary,
jack, linux-fsdevel, linux-kernel, lossin, ojeda, rust-for-linux,
tmgross, viro
Thanks for the reminder.Got it. I'll make sure to send future versions
as completely separate threads.
在 2026/5/16 15:57, Onur Özkan 写道:
> On Sat, 16 May 2026 12:08:12 +0800
> Yifei Yao <donplat@barrensea.org> wrote:
>
>> Currently, the `seq_print!` macro formats output by passing a Rust
>> `fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
>> This involves crossing the FFI boundary, parsing the
>> format string in C via `vsnprintf`, and triggering a callback back
>> into Rust to perform the actual buffer write.
>>
>> This patch implements `core::fmt::Write` for `&SeqFile` and updates
>> `call_printf` to use it, routing Rust's formatting directly to
>> `bindings::seq_write`. This approach leverages the bounded string
>> slices naturally produced by the Rust formatting machinery and copies
>> them directly into the `seq_file` buffer.
>>
>> By mapping to `seq_write`, we bypass the C string parsing state machine
>> and the `%pA` FFI callback, streamlining the execution path. Since
>> `seq_write` uses a bounded `memcpy` relying on the explicitly passed
>> length, it perfectly matches Rust's `&str` semantics and operates
>> safely without requiring null-termination.
>>
>> Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
>> If an overflow occurs during a partial write, `seq_write` sets the
>> overflow flag. The `seq_file` subsystem inherently handles this by
>> discarding the current record and retrying with a larger buffer.
>> Therefore, this optimization introduces no observable semantic change
>> to user-space.
>>
>> Signed-off-by: Yifei Yao <donplat@barrensea.org>
>> ---
>>
>> Changes in v2:
>> - Add `#[inline]` annotation to the `write_str` trait method.
>> - Fix author name and signed-off name to use real name per the kernel's
>> DCO policy.
>> - Correctly check the return value of `seq_write` and propagates errors on overflow.
>>
>> rust/kernel/seq_file.rs | 32 ++++++++++++++++++++++++--------
>> 1 file changed, 24 insertions(+), 8 deletions(-)
>>
>> diff --git a/rust/kernel/seq_file.rs b/rust/kernel/seq_file.rs
>> index 518265558d6..d7dbdadde60 100644
>> --- a/rust/kernel/seq_file.rs
>> +++ b/rust/kernel/seq_file.rs
>> @@ -4,7 +4,7 @@
>> //!
>> //! C header: [`include/linux/seq_file.h`](srctree/include/linux/seq_file.h)
>>
>> -use crate::{bindings, fmt, str::CStrExt as _, types::NotThreadSafe, types::Opaque};
>> +use crate::{bindings, ffi::c_void, fmt, types::NotThreadSafe, types::Opaque};
>>
>> /// A utility for generating the contents of a seq file.
>> #[repr(transparent)]
>> @@ -32,13 +32,29 @@ pub unsafe fn from_raw<'a>(ptr: *mut bindings::seq_file) -> &'a SeqFile {
>> /// Used by the [`seq_print`] macro.
>> #[inline]
>> pub fn call_printf(&self, args: fmt::Arguments<'_>) {
>> - // SAFETY: Passing a void pointer to `Arguments` is valid for `%pA`.
>> - unsafe {
>> - bindings::seq_printf(
>> - self.inner.get(),
>> - c"%pA".as_char_ptr(),
>> - core::ptr::from_ref(&args).cast::<crate::ffi::c_void>(),
>> - );
>> + let mut this = self;
>> + let _ = fmt::Write::write_fmt(&mut this, args);
>> + }
>> +}
>> +
>> +impl fmt::Write for &SeqFile {
>> + #[inline]
>> + fn write_str(&mut self, s: &str) -> fmt::Result {
>> + // SAFETY: `self` is a valid reference, ensuring `self.inner.get()` is a valid pointer
>> + // to `struct seq_file`. `s` is a valid string slice, guaranteeing `s.as_ptr()` is
>> + // readable for `s.len()` bytes. `seq_write` handles bounds checking and does not
>> + // require a null-terminated string.
>> + //
>> + // CAST: `s.as_ptr()` (a `*const u8`) is cast to `*const c_void` because `seq_write`
>> + // only reads the buffer via `memcpy` and does not care about the underlying type.
>> +
>> + let res =
>> + unsafe { bindings::seq_write(self.inner.get(), s.as_ptr().cast::<c_void>(), s.len()) };
>> +
>> + if res < 0 {
>> + Err(fmt::Error)
>> + } else {
>> + Ok(())
>> }
>> }
>> }
>> --
>> 2.53.0
>>
> FYI new versions are usually sent separately.
>
> Onur
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] rust: seq_file: route seq_print! directly to seq_write
2026-05-16 4:08 ` [PATCH v2] " Yifei Yao
2026-05-16 7:57 ` Onur Özkan
@ 2026-05-16 19:34 ` Gary Guo
1 sibling, 0 replies; 6+ messages in thread
From: Gary Guo @ 2026-05-16 19:34 UTC (permalink / raw)
To: Yifei Yao
Cc: a.hindborg, aliceryhl, bjorn3_gh, boqun, brauner, dakr, gary,
jack, linux-fsdevel, linux-kernel, lossin, ojeda, rust-for-linux,
tmgross, viro
On Sat May 16, 2026 at 5:08 AM BST, Yifei Yao wrote:
> Currently, the `seq_print!` macro formats output by passing a Rust
> `fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
> This involves crossing the FFI boundary, parsing the
> format string in C via `vsnprintf`, and triggering a callback back
> into Rust to perform the actual buffer write.
>
> This patch implements `core::fmt::Write` for `&SeqFile` and updates
> `call_printf` to use it, routing Rust's formatting directly to
> `bindings::seq_write`. This approach leverages the bounded string
> slices naturally produced by the Rust formatting machinery and copies
> them directly into the `seq_file` buffer.
>
> By mapping to `seq_write`, we bypass the C string parsing state machine
> and the `%pA` FFI callback, streamlining the execution path. Since
> `seq_write` uses a bounded `memcpy` relying on the explicitly passed
> length, it perfectly matches Rust's `&str` semantics and operates
> safely without requiring null-termination.
>
> Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
> If an overflow occurs during a partial write, `seq_write` sets the
> overflow flag. The `seq_file` subsystem inherently handles this by
> discarding the current record and retrying with a larger buffer.
> Therefore, this optimization introduces no observable semantic change
> to user-space.
Seems that this description is AI-generated. If you used them this must be
disclosed per kernel policy:
https://docs.kernel.org/process/coding-assistants.html.
What's the benefit of this change? Given a single "%pA" string vsnprintf doesn't
do much before passing it back to the Rust formatting machinery. `seq_printf`
just formats directly into its internal buffer, so it's not like there's any
additional copy being optimized out with this change.
This also changes the behaviour when write does overflow, where the previous
code would write as much as possible to the buffer and the new one would not
write anything if the last chunk being written would cause overflow.
Best,
Gary
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-05-16 19:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-14 5:37 [PATCH] rust: seq_file: route seq_print! directly to seq_write Donjuanplatinum
2026-05-14 7:04 ` Greg KH
2026-05-16 4:08 ` [PATCH v2] " Yifei Yao
2026-05-16 7:57 ` Onur Özkan
2026-05-16 8:21 ` donplat
2026-05-16 19:34 ` Gary Guo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox