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>,
"Benno Lossin" <benno.lossin@proton.me>,
"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>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v4 1/4] rust: debugfs: Bind DebugFS directory creation
Date: Sat, 3 May 2025 14:36:26 +0200 [thread overview]
Message-ID: <aBYNyqTRlpGAJVuB@polis> (raw)
In-Reply-To: <20250502-debugfs-rust-v4-1-788a9c6c2e77@google.com>
On Fri, May 02, 2025 at 07:49:30PM +0000, Matthew Maurer wrote:
> +/// Owning handle to a DebugFS directory.
> +///
> +/// This directory will be cleaned up when it goes out of scope.
> +///
> +/// # Invariants
> +///
> +/// The wrapped pointer will always be `NULL`, an error, or an owned DebugFS `dentry`.
> +#[repr(transparent)]
> +pub struct Dir<'a, const KEEP: bool = false> {
Why did you move to a const generic, rather than a new type? What's the
advantage? AFAICS, it just makes it less obvious to see from the type itself how
it will behave. Reading Dir<true> doesn't make it obvious what it does.
While I prefer a new type over the const generic, I'm fine with it. But I think
we should use something more descriptive than a bool. Please see
device::DeviceContext for reference.
> + /// Create a DebugFS subdirectory.
> + ///
> + /// This returns a [`Dir<'_, true>`], which will not be automatically cleaned up when it
> + /// leaves scope.
> + /// To convert this to a handle governing the lifetime of the directory, use [`Dir::owning`].
> + ///
> + /// Regardless of conversion, subdirectory handles cannot outlive the directory handle they
> + /// were created from.
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// # use kernel::c_str;
> + /// # use kernel::debugfs::Dir;
> + /// let parent = Dir::new(c_str!("parent"));
> + /// let child = parent.subdir(c_str!("child"));
> + /// ```
> + pub fn subdir<'b>(&'b self, name: &CStr) -> Dir<'b, true> {
> + Dir::create(name, Some(self))
> + }
The default should be that the directory is removed when the Dir instance is
dropped.
The common case (which people expect) is that an object is cleaned up on drop().
> +impl<'a> Dir<'a, true> {
> + /// Upgrade a non-owning directory to one which will be removed on drop.
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// # use kernel::c_str;
> + /// # use kernel::debugfs::Dir;
> + /// let debugfs = Dir::new(c_str!("parent"));
> + /// let subdir = debugfs.subdir(c_str!("child"));
> + /// // If subdir were dropped, the directory would not be removed.
> + /// let owned_subdir = subdir.owning();
> + /// // If owned_subdir is dropped, "child" will be removed.
> + /// ```
> + pub fn owning(self) -> Dir<'a, false> {
> + Dir {
> + dir: self.dir,
> + _phantom: self._phantom,
> + }
> + }
As mentioned above, please make it the other way around.
next prev parent reply other threads:[~2025-05-03 12:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 19:49 [PATCH v4 0/4] rust: DebugFS Bindings Matthew Maurer
2025-05-02 19:49 ` [PATCH v4 1/4] rust: debugfs: Bind DebugFS directory creation Matthew Maurer
2025-05-03 12:36 ` Danilo Krummrich [this message]
2025-05-05 16:21 ` Matthew Maurer
2025-05-05 16:29 ` Greg Kroah-Hartman
2025-05-05 16:31 ` Matthew Maurer
2025-05-05 16:48 ` Danilo Krummrich
2025-05-02 19:49 ` [PATCH v4 2/4] rust: debugfs: Bind file creation for long-lived Display Matthew Maurer
2025-05-03 12:44 ` Danilo Krummrich
2025-05-02 19:49 ` [PATCH v4 3/4] rust: debugfs: Support format hooks Matthew Maurer
2025-05-02 19:49 ` [PATCH v4 4/4] rust: samples: Add debugfs sample Matthew Maurer
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=aBYNyqTRlpGAJVuB@polis \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.