rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Matthew Maurer <mmaurer@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Sami Tolvanen" <samitolvanen@google.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Benno Lossin" <lossin@kernel.org>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v6 2/5] rust: debugfs: Bind file creation for long-lived Display
Date: Wed, 18 Jun 2025 17:39:05 +0200	[thread overview]
Message-ID: <aFLdmYLyDucTAiZx@pollux> (raw)
In-Reply-To: <20250618-debugfs-rust-v6-2-72cae211b133@google.com>

On Wed, Jun 18, 2025 at 02:28:14AM +0000, Matthew Maurer wrote:
> diff --git a/rust/kernel/debugfs/display_file.rs b/rust/kernel/debugfs/display_file.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..65e37e34d7b587482492dc296637a3bc517b9fe3
> --- /dev/null
> +++ b/rust/kernel/debugfs/display_file.rs
> @@ -0,0 +1,60 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2025 Google LLC.
> +
> +use crate::seq_file::SeqFile;
> +use crate::seq_print;
> +use core::fmt::Display;
> +
> +/// Implements `open` for `file_operations` via `single_open` to fill out a `seq_file`.
> +///
> +/// # Safety
> +///
> +/// * `inode`'s private pointer must point to a value of type `T` which will outlive the `inode`
> +///   and will not be mutated during this call.
> +/// * `file` must point to a live, not-yet-initialized file object.
> +pub(crate) unsafe extern "C" fn display_open<T: Display>(
> +    inode: *mut bindings::inode,
> +    file: *mut bindings::file,
> +) -> i32 {

Please use kernel::ffi::c_int instead.

> +    // SAFETY:
> +    // * `file` is acceptable by caller precondition.
> +    // * `print_act` will be called on a `seq_file` with private data set to the third argument,
> +    //   so we meet its safety requirements.
> +    // * The `data` pointer passed in the third argument is a valid `T` pointer that outlives
> +    //   this call by caller preconditions.
> +    unsafe { bindings::single_open(file, Some(display_act::<T>), (*inode).i_private) }
> +}
> +
> +/// Prints private data stashed in a seq_file to that seq file.
> +///
> +/// # Safety
> +///
> +/// `seq` must point to a live `seq_file` whose private data is a live pointer to a `T` which is
> +/// not being mutated.
> +pub(crate) unsafe extern "C" fn display_act<T: Display>(
> +    seq: *mut bindings::seq_file,
> +    _: *mut core::ffi::c_void,
> +) -> i32 {

kernel::ffi::c_int

> +    // SAFETY: By caller precondition, this pointer is live, points to a value of type `T`, and
> +    // is not being mutated.
> +    let data = unsafe { &*((*seq).private as *mut T) };
> +    // SAFETY: By caller precondition, `seq_file` points to a live `seq_file`, so we can lift
> +    // it.
> +    let seq_file = unsafe { SeqFile::from_raw(seq) };
> +    seq_print!(seq_file, "{}", data);
> +    0
> +}
> +
> +// Work around lack of generic const items.
> +pub(crate) trait DisplayFile: Display + Sized {
> +    const VTABLE: bindings::file_operations = bindings::file_operations {
> +        read: Some(bindings::seq_read),
> +        llseek: Some(bindings::seq_lseek),
> +        release: Some(bindings::single_release),
> +        open: Some(display_open::<Self> as _),

Why the cast? That shouldn't be needed.

> +        // SAFETY: `file_operations` supports zeroes in all fields.
> +        ..unsafe { core::mem::zeroed() }
> +    };
> +}

  reply	other threads:[~2025-06-18 15:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18  2:28 [PATCH v6 0/5] rust: DebugFS Bindings Matthew Maurer
2025-06-18  2:28 ` [PATCH v6 1/5] rust: debugfs: Bind DebugFS directory creation Matthew Maurer
2025-06-18 10:04   ` Danilo Krummrich
2025-06-18  2:28 ` [PATCH v6 2/5] rust: debugfs: Bind file creation for long-lived Display Matthew Maurer
2025-06-18 15:39   ` Danilo Krummrich [this message]
2025-06-18 15:56     ` Alice Ryhl
2025-06-18  2:28 ` [PATCH v6 3/5] rust: debugfs: Support arbitrary owned backing for File Matthew Maurer
2025-06-18  8:19   ` Alice Ryhl
2025-06-18 15:00     ` Matthew Maurer
2025-06-18 15:32       ` Danilo Krummrich
2025-06-18  2:28 ` [PATCH v6 4/5] rust: debugfs: Support format hooks Matthew Maurer
2025-06-18  2:28 ` [PATCH v6 5/5] rust: samples: Add debugfs sample Matthew Maurer
2025-06-18 15:52   ` Danilo Krummrich
2025-06-18  8:21 ` [PATCH v6 0/5] rust: DebugFS Bindings Alice Ryhl
2025-06-24 11:37 ` Dirk Behme

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=aFLdmYLyDucTAiZx@pollux \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=mmaurer@google.com \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samitolvanen@google.com \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    /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;
as well as URLs for NNTP newsgroup(s).