From: donplat <donplat@barrensea.org>
To: "Onur Özkan" <work@onurozkan.dev>
Cc: a.hindborg@kernel.org, aliceryhl@google.com,
bjorn3_gh@protonmail.com, boqun@kernel.org, brauner@kernel.org,
dakr@kernel.org, gary@garyguo.net, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
lossin@kernel.org, ojeda@kernel.org,
rust-for-linux@vger.kernel.org, tmgross@umich.edu,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH v2] rust: seq_file: route seq_print! directly to seq_write
Date: Sat, 16 May 2026 16:21:19 +0800 [thread overview]
Message-ID: <faafb47e-9502-4d4b-b14e-b8a5668af355@barrensea.org> (raw)
In-Reply-To: <20260516075732.316054-1-work@onurozkan.dev>
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
next prev parent reply other threads:[~2026-05-16 8:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 5:37 [PATCH] " 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 [this message]
2026-05-16 19:34 ` Gary Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=faafb47e-9502-4d4b-b14e-b8a5668af355@barrensea.org \
--to=donplat@barrensea.org \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=brauner@kernel.org \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=work@onurozkan.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®