rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Benno Lossin <lossin@kernel.org>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org, ojeda@kernel.org,
	alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
	bjorn3_gh@protonmail.com, benno.lossin@proton.me,
	a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
	chrisi.schrefl@gmail.com, rust-for-linux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] rust: miscdevice: expose the parent device as &Device<Bound>
Date: Sat, 31 May 2025 12:46:49 +0200	[thread overview]
Message-ID: <aDreGUcvyR4kjMGl@pollux> (raw)
In-Reply-To: <DAA7CJOUJPNL.F7UH9KD8JANF@kernel.org>

On Sat, May 31, 2025 at 10:27:44AM +0200, Benno Lossin wrote:
> On Fri May 30, 2025 at 4:24 PM CEST, Danilo Krummrich wrote:
> > @@ -227,11 +229,21 @@ fn drop(self: Pin<&mut Self>) {
> >      }
> >  }
> >  
> > +/// The arguments passed to the file operation callbacks of a [`MiscDeviceRegistration`].
> > +pub struct MiscArgs<'a, T: MiscDevice> {
> > +    /// The [`Device`] representation of the `struct miscdevice`.
> > +    pub device: &'a Device,
> > +    /// The parent [`Device`] of [`Self::device`].
> > +    pub parent: Option<&'a Device<Bound>>,
> > +    /// The `RegistrationData` passed to [`MiscDeviceRegistration::register`].
> > +    pub data: &'a T::RegistrationData,
> 
> Here I would also just use `T`, remove the `MiscDevice` bound and then
> use `MiscArgs<'_, Self::RegistrationData>` below.

It has the disadvantage that the documentation of the `data` field above needs
to be much more vague, since we can't claim that it's the `RegistrationData`
passed to `MiscDeviceRegistration::register` anymore -- given that, I'm not sure
it's worth changing.

> > +}
> > +
> >  /// Trait implemented by the private data of an open misc device.
> >  #[vtable]
> >  pub trait MiscDevice: Sized {
> >      /// What kind of pointer should `Self` be wrapped in.
> > -    type Ptr: ForeignOwnable + Send + Sync;
> > +    type Ptr: Send + Sync;
> 
> There is no info about this change in the commit message. Why are we
> changing this? This seems a bit orthogonal to the other change, maybe do
> it in a separate patch?

It's a consequence of the implementation:

A `Ptr` instance is created in the misc device's file operations open() callback
and dropped in the fops release() callback.

Previously, this was stored in the private data pointer of the struct file that
is passed for every file operation in open().

Also note that when open is called the private data pointer in a struct file
points to the corresponding struct miscdevice.

With this patch, we keep the pointer to the struct miscdevice in the private
data pointer of struct file, but instead store the `Ptr` instance in
`RawDeviceRegistration::private`.

Subsequently, ForeignOwnable is not a required trait anymore.

We need this in order to keep access to the `RawDeviceRegistration` throughout
file operations to be able to pass the misc device's parent as &Device<Bound>
through the `MiscArgs` above.

> Also `Ptr` doesn't make much sense for the name, since now that the
> `ForeignOwnable` bound is gone, I could set this to `Self` and then have
> access to `&Self` in the callbacks.

We can't make it `Self`, it might still be some pointer type, require pin-init,
etc. So, it has to be a generic type.

But, I agree that we should not name it `Ptr`, probably should never have been
named `Ptr`, but `Data`, `Private` or similar.

> Would that also make sense to use as a general change? So don't store
> `Self::Ptr`, but `Self` directly?

I think it can't be `Self`, see above.

  reply	other threads:[~2025-05-31 10:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30 14:24 [PATCH 0/7] misc device: support device drivers Danilo Krummrich
2025-05-30 14:24 ` [PATCH 1/7] rust: types: support fallible PinInit types in Opaque::pin_init Danilo Krummrich
2025-05-30 16:14   ` Christian Schrefl
2025-05-30 19:29   ` Benno Lossin
2025-05-30 20:11     ` Christian Schrefl
2025-05-30 21:27       ` Benno Lossin
2025-05-30 21:52       ` Danilo Krummrich
2025-05-30 14:24 ` [PATCH 2/7] rust: revocable: support fallible PinInit types Danilo Krummrich
2025-05-30 16:15   ` Christian Schrefl
2025-05-30 19:31   ` Benno Lossin
2025-05-30 14:24 ` [PATCH 3/7] rust: devres: support fallible in-place init for data Danilo Krummrich
2025-05-30 16:18   ` Christian Schrefl
2025-05-30 19:33   ` Benno Lossin
2025-05-30 14:24 ` [PATCH 4/7] rust: faux: impl AsRef<Device<Bound>> for Registration Danilo Krummrich
2025-05-30 14:24 ` [PATCH 5/7] rust: miscdevice: properly support device drivers Danilo Krummrich
2025-05-30 17:35   ` Christian Schrefl
2025-05-30 18:38     ` Danilo Krummrich
2025-05-30 20:06   ` Benno Lossin
2025-05-30 22:17     ` Danilo Krummrich
2025-05-31  8:05       ` Benno Lossin
2025-05-31 10:33         ` Danilo Krummrich
2025-05-30 14:24 ` [PATCH 6/7] rust: miscdevice: expose the parent device as &Device<Bound> Danilo Krummrich
2025-05-31  8:27   ` Benno Lossin
2025-05-31 10:46     ` Danilo Krummrich [this message]
2025-05-31 12:10       ` Benno Lossin
2025-05-31 12:39         ` Danilo Krummrich
2025-05-31 15:23           ` Benno Lossin
2025-05-30 14:24 ` [PATCH 7/7] rust: sample: misc: implement device driver sample Danilo Krummrich
2025-05-30 20:15   ` Benno Lossin
2025-05-30 22:24     ` Danilo Krummrich
2025-05-31  8:11       ` Benno Lossin
2025-05-31 10:29         ` Danilo Krummrich
2025-05-31 12:03           ` Benno Lossin
2025-05-31 12:24             ` Danilo Krummrich
2025-05-31 11:05         ` Miguel Ojeda
2025-05-30 16:37 ` [PATCH 0/7] misc device: support device drivers Christian Schrefl
2025-05-30 17:29   ` Christian Schrefl
2025-05-30 19:24     ` Benno Lossin
2025-05-30 19:35       ` Boqun Feng
2025-05-30 19:36         ` Boqun Feng
2025-05-30 18:45   ` Danilo Krummrich
2025-05-30 19:25 ` Benno Lossin

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=aDreGUcvyR4kjMGl@pollux \
    --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=chrisi.schrefl@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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).