[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALNs47sqzqWzE-5srCq7_ePVx3HGaJ9EkwGbbFnqH9xCJXDByw@mail.gmail.com>
Date: Wed, 17 Jan 2024 20:05:55 -0500
From: Trevor Gross <tmgross@...ch.edu>
To: Valentin Obst <kernel@...entinobst.de>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>,
Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/13] rust: kernel: unify spelling of refcount in docs
On Tue, Jan 16, 2024 at 5:37 PM Valentin Obst <kernel@...entinobst.de> wrote:
>
> Replace instances of 'ref-count[ed]' with 'refcount[ed]' to increase
> consistency within the Rust documentation. The latter form is used more
> widely in the rest of the kernel:
>
> ```console
> $ rg '(\*|//).*?\srefcount(|ed)[\s,.]' | wc -l
> 1605
> $ rg '(\*|//).*?\sref-count(|ed)[\s,.]' | wc -l
> 43
> ```
>
> (numbers are for Commit 052d534373b7)
>
> Signed-off-by: Valentin Obst <kernel@...entinobst.de>
> ---
> rust/kernel/sync/arc.rs | 8 ++++----
> rust/kernel/task.rs | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index 77cdbcf7bd2e..6c46b1affca5 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -56,7 +56,7 @@
> /// b: u32,
> /// }
> ///
> -/// // Create a ref-counted instance of `Example`.
> +/// // Create a refcounted instance of `Example`.
> /// let obj = Arc::try_new(Example { a: 10, b: 20 })?;
> ///
> /// // Get a new pointer to `obj` and increment the refcount.
> @@ -510,7 +510,7 @@ fn deref(&self) -> &Self::Target {
> /// # test().unwrap();
> /// ```
> ///
> -/// In the following example we first allocate memory for a ref-counted `Example` but we don't
> +/// In the following example we first allocate memory for a refcounted `Example` but we don't
> /// initialise it on allocation. We do initialise it later with a call to [`UniqueArc::write`],
> /// followed by a conversion to `Arc<Example>`. This is particularly useful when allocation happens
> /// in one context (e.g., sleepable) and initialisation in another (e.g., atomic):
> @@ -560,7 +560,7 @@ impl<T> UniqueArc<T> {
> /// Tries to allocate a new [`UniqueArc`] instance.
> pub fn try_new(value: T) -> Result<Self, AllocError> {
> Ok(Self {
> - // INVARIANT: The newly-created object has a ref-count of 1.
> + // INVARIANT: The newly-created object has a refcount of 1.
> inner: Arc::try_new(value)?,
> })
> }
> @@ -574,7 +574,7 @@ pub fn try_new_uninit() -> Result<UniqueArc<MaybeUninit<T>>, AllocError> {
> data <- init::uninit::<T, AllocError>(),
> }? AllocError))?;
> Ok(UniqueArc {
> - // INVARIANT: The newly-created object has a ref-count of 1.
> + // INVARIANT: The newly-created object has a refcount of 1.
> // SAFETY: The pointer from the `Box` is valid.
> inner: unsafe { Arc::from_inner(Box::leak(inner).into()) },
> })
> diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> index 9451932d5d86..818ac51b06b6 100644
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@ -23,7 +23,7 @@ macro_rules! current {
> ///
> /// All instances are valid tasks created by the C portion of the kernel.
> ///
> -/// Instances of this type are always ref-counted, that is, a call to `get_task_struct` ensures
> +/// Instances of this type are always refcounted, that is, a call to `get_task_struct` ensures
> /// that the allocation remains valid at least until the matching call to `put_task_struct`.
> ///
> /// # Examples
> @@ -147,7 +147,7 @@ pub fn wake_up(&self) {
> }
> }
>
> -// SAFETY: The type invariants guarantee that `Task` is always ref-counted.
> +// SAFETY: The type invariants guarantee that `Task` is always refcounted.
> unsafe impl crate::types::AlwaysRefCounted for Task {
> fn inc_ref(&self) {
> // SAFETY: The existence of a shared reference means that the refcount is nonzero.
> --
> 2.43.0
>
Reviewed-by: Trevor Gross <tmgross@...ch.edu>
Powered by blists - more mailing lists