All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benno Lossin" <lossin@kernel.org>
To: "Danilo Krummrich" <dakr@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>
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>, <a.hindborg@kernel.org>,
	<aliceryhl@google.com>, <tmgross@umich.edu>,
	<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] device: rust: documentation for DeviceContext
Date: Mon, 21 Jul 2025 15:48:06 +0200	[thread overview]
Message-ID: <DBHS3M032PU8.3UCTIWJB5COOZ@kernel.org> (raw)
In-Reply-To: <DBF7IACHZEUW.29EHD3V4OF5GA@kernel.org>

On Fri Jul 18, 2025 at 3:14 PM CEST, Danilo Krummrich wrote:
> On Fri Jul 18, 2025 at 2:32 PM CEST, Alexandre Courbot wrote:
>> On Fri Jul 18, 2025 at 7:45 AM JST, Danilo Krummrich wrote:
>>> +///
>>> +/// Bus devices can automatically implement the dereference hierarchy by using
>>> +/// [`impl_device_context_deref`](kernel::impl_device_context_deref).
>>>  pub trait DeviceContext: private::Sealed {}
>>>  
>>> -/// The [`Normal`] context is the context of a bus specific device when it is not an argument of
>>> -/// any bus callback.
>>> +/// The [`Normal`] context is the default [`DeviceContext`] of any [`Device`].
>>> +///
>>> +/// The normal context does not indicate any specific scope. Any `Device<Ctx>` is also a valid
>>> +/// [`Device<Normal>`]. It is the only [`DeviceContext`] for which it is valid to implement
>>> +/// [`AlwaysRefCounted`](kernel::types::AlwaysRefCounted) for.
>>>  pub struct Normal;
>>
>> `Normal` as a name can be interpreted in many different ways, and in the
>> case of a device context it is not clear what the "normal" state is. I
>> think it would be helpful if we can elaborate a bit more on what this
>> implies (i.e. what concretely speaking are the limitations), and if
>> possible why this name has been chosen.
>
> It's the context that does not guarantee any specific scope. But that's also
> what the documentation says.
>
> I also wouldn't speak of limitations, it's just that it doesn't allow to make
> *additional* assumptions compared to other device context types.
>
> Yet, if you have suggestions on what to add specifically, please let me know
> (maybe simply my previous sentence?).
>
> Regarding the name, "Normal" seems reasonable for the device context that does
> not guarantee any specific scope. We could have also named it just "Default".
>
> I think "Normal" is fine, as in "it's just a normal device reference, no
> specific scope guaranteed".

Not sure if this helps, but `Plain` might carry a slightly different
meaning from `Normal` that is better in this case?

(but you probably can't infer much from the name anyways)

---
Cheers,
Benno

  reply	other threads:[~2025-07-21 13:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 22:45 [PATCH 0/3] Documentation for Device / Driver infrastructure Danilo Krummrich
2025-07-17 22:45 ` [PATCH 1/3] device: rust: documentation for DeviceContext Danilo Krummrich
2025-07-18 12:32   ` Alexandre Courbot
2025-07-18 13:14     ` Danilo Krummrich
2025-07-21 13:48       ` Benno Lossin [this message]
2025-07-18 13:09   ` Daniel Almeida
2025-07-18 14:16     ` Danilo Krummrich
2025-07-20 15:45       ` Daniel Almeida
2025-07-17 22:45 ` [PATCH 2/3] device: rust: expand documentation for Device Danilo Krummrich
2025-07-20 15:56   ` Daniel Almeida
2025-07-21 11:26   ` Alice Ryhl
2025-07-21 11:42     ` Greg KH
2025-07-21 12:07       ` Alice Ryhl
2025-07-21 12:13         ` Danilo Krummrich
2025-07-21 13:17           ` Greg KH
2025-07-21 13:41             ` Danilo Krummrich
2025-07-21 12:07     ` Danilo Krummrich
2025-07-17 22:45 ` [PATCH 3/3] driver: rust: expand documentation for driver infrastructure Danilo Krummrich
2025-07-20 15:57   ` Daniel Almeida
2025-07-19  7:56 ` [PATCH 0/3] Documentation for Device / Driver infrastructure Greg KH

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=DBHS3M032PU8.3UCTIWJB5COOZ@kernel.org \
    --to=lossin@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.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 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.