Re: [PATCH v2] rust: seq_file: route seq_print! directly to seq_write

["Gary Guo" <gary@garyguo.net>]

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