All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rafael@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com,
	wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
	bjorn3_gh@protonmail.com, benno.lossin@proton.me,
	a.hindborg@samsung.com, aliceryhl@google.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	rust-for-linux@vger.kernel.org, x86@kernel.org, lyude@redhat.com,
	pstanner@redhat.com, ajanulgu@redhat.com, airlied@redhat.com
Subject: Re: [PATCH 7/8] rust: add revocable objects
Date: Tue, 26 Mar 2024 22:48:19 +0100	[thread overview]
Message-ID: <ZgNCo4Hvs-EjDNGT@pollux> (raw)
In-Reply-To: <2024032637-nervous-blustery-2566@gregkh>

On Tue, Mar 26, 2024 at 07:16:51PM +0100, Greg KH wrote:
> On Tue, Mar 26, 2024 at 06:07:36PM +0100, Danilo Krummrich wrote:
> > On Mon, Mar 25, 2024 at 07:21:32PM +0100, Greg KH wrote:
> > > On Mon, Mar 25, 2024 at 06:49:11PM +0100, Danilo Krummrich wrote:
> > > > From: Wedson Almeida Filho <wedsonaf@gmail.com>
> > > > 
> > > > This implements the Revocable and AsyncRevocable types.
> > > > 
> > > > Revocable allows access to objects to be safely revoked at run time.
> > > > 
> > > > This is useful, for example, for resources allocated during device probe;
> > > > when the device is removed, the driver should stop accessing the device
> > > > resources even if other state is kept in memory due to existing
> > > > references (i.e., device context data is ref-counted and has a non-zero
> > > > refcount after removal of the device).
> > > 
> > > Again, device removal is different from unbinding a driver from a
> > > device.  Please fix this all up.
> > 
> > I think this isn't an "again", "[PATCH 8/8] rust: add device::Data" actually
> > phrased things differently (which indeed isn't great and needs to be fixed).
> > 
> > This comment indeed implies that device removal actually means unbinding a
> > driver from a device. I think "device remove" is meant here as the drivers
> > remove() callback is called.
> > 
> > Your comment seems to imply you have a different understanding of what "device
> > remove" means?
> 
> Yes, see my other comments.  A device has a lifespan that exceeds that
> of a driver, and "remove" does not mean it is gone from the system just
> because the remove() callback of a single driver is called.  It still
> can, and does, live outside of a driver quite well, and in fact, the
> driver is not in control of its lifespan at all!

Yes, that's clear. But what does "device remove" mean for you then?

I think this one here mostly seems to be about terminology and I want to make
sure I don't create any other misunderstandings e.g. by using "device remove"
for unbinding a driver from a device.

> 
> All a driver can know is that it has a valid reference to a device for
> the amount of time from probe() to remove().  Outside of that a driver
> can not touch it, BUT the device structure lives on and can do lots of
> other things that do not involve the driver at all.
> 
> thanks,
> 
> greg k-h
> 


  reply	other threads:[~2024-03-26 21:48 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25 17:49 [PATCH 0/8] [RFC] Rust device / driver abstractions Danilo Krummrich
2024-03-25 17:49 ` [PATCH 1/8] arch: x86: tools: increase symbol name size Danilo Krummrich
2024-03-25 17:53   ` Miguel Ojeda
2024-03-25 18:01     ` Danilo Krummrich
2024-03-25 18:18       ` Miguel Ojeda
2024-03-25 17:49 ` [PATCH 2/8] rust: device: Add a minimal RawDevice trait Danilo Krummrich
2024-03-25 18:14   ` Greg KH
2024-03-25 18:22     ` Miguel Ojeda
2024-03-26 22:38     ` Danilo Krummrich
2024-03-27  5:25       ` Greg KH
2024-03-27 11:39         ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 3/8] rust: device: Add a stub abstraction for devices Danilo Krummrich
2024-03-25 17:58   ` Boqun Feng
2024-03-27 11:36     ` Danilo Krummrich
2024-03-25 18:14   ` Greg KH
2024-03-25 18:17   ` Greg KH
2024-03-26 16:01     ` Danilo Krummrich
2024-03-26 18:03       ` Greg KH
2024-03-26 19:03         ` Boqun Feng
2024-03-26 21:01         ` Danilo Krummrich
2024-03-27  1:38     ` Wedson Almeida Filho
2024-03-27  5:22       ` Greg KH
2024-03-27  9:05         ` Philipp Stanner
2024-03-27  9:13           ` Greg KH
2024-03-27 11:35         ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 4/8] rust: add driver abstraction Danilo Krummrich
2024-03-25 18:12   ` Greg KH
2024-03-25 18:30   ` Greg KH
2024-03-25 19:36     ` David Airlie
2024-03-26  5:37       ` Greg KH
2024-03-26  6:02         ` David Airlie
2024-03-26  6:14           ` Greg KH
2024-03-26  6:34             ` David Airlie
2024-03-31 19:17               ` Fabien Parent
2024-04-02 13:51                 ` Danilo Krummrich
2024-03-28 10:41   ` Viresh Kumar
2024-03-25 17:49 ` [PATCH 5/8] rust: add rcu abstraction Danilo Krummrich
2024-03-25 17:49 ` [PATCH 6/8] rust: add revocable mutex Danilo Krummrich
2024-03-25 18:22   ` Greg KH
2024-03-26 18:13     ` Danilo Krummrich
2024-03-26 18:17       ` Greg KH
2024-03-26 21:32         ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 7/8] rust: add revocable objects Danilo Krummrich
2024-03-25 18:21   ` Greg KH
2024-03-26 17:07     ` Danilo Krummrich
2024-03-26 18:16       ` Greg KH
2024-03-26 21:48         ` Danilo Krummrich [this message]
2024-03-27  1:31     ` Wedson Almeida Filho
2024-03-25 17:49 ` [PATCH 8/8] rust: add device::Data Danilo Krummrich
2024-03-25 18:21   ` Greg KH
2024-03-26 16:54     ` Danilo Krummrich
2024-03-26 18:12       ` Greg KH
2024-03-26 22:24         ` Danilo Krummrich

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=ZgNCo4Hvs-EjDNGT@pollux \
    --to=dakr@redhat.com \
    --cc=a.hindborg@samsung.com \
    --cc=airlied@redhat.com \
    --cc=ajanulgu@redhat.com \
    --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=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=lyude@redhat.com \
    --cc=mingo@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=pstanner@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wedsonaf@gmail.com \
    --cc=x86@kernel.org \
    /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.