rust: kernel: add doclinks
Add doclinks to existing documentation. Signed-off-by: Valentin Obst <kernel@valentinobst.de> Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240131-doc-fixes-v3-v3-10-0c8af94ed7de@valentinobst.de Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This commit is contained in:
committed by
Miguel Ojeda
parent
6269fadf35
commit
4c799d1dc8
@@ -365,12 +365,12 @@ impl<T: ?Sized> From<Pin<UniqueArc<T>>> for Arc<T> {
|
||||
/// A borrowed reference to an [`Arc`] instance.
|
||||
///
|
||||
/// For cases when one doesn't ever need to increment the refcount on the allocation, it is simpler
|
||||
/// to use just `&T`, which we can trivially get from an `Arc<T>` instance.
|
||||
/// to use just `&T`, which we can trivially get from an [`Arc<T>`] instance.
|
||||
///
|
||||
/// However, when one may need to increment the refcount, it is preferable to use an `ArcBorrow<T>`
|
||||
/// over `&Arc<T>` because the latter results in a double-indirection: a pointer (shared reference)
|
||||
/// to a pointer (`Arc<T>`) to the object (`T`). An [`ArcBorrow`] eliminates this double
|
||||
/// indirection while still allowing one to increment the refcount and getting an `Arc<T>` when/if
|
||||
/// to a pointer ([`Arc<T>`]) to the object (`T`). An [`ArcBorrow`] eliminates this double
|
||||
/// indirection while still allowing one to increment the refcount and getting an [`Arc<T>`] when/if
|
||||
/// needed.
|
||||
///
|
||||
/// # Invariants
|
||||
|
||||
@@ -21,14 +21,21 @@ pub mod spinlock;
|
||||
/// # Safety
|
||||
///
|
||||
/// - Implementers must ensure that only one thread/CPU may access the protected data once the lock
|
||||
/// is owned, that is, between calls to `lock` and `unlock`.
|
||||
/// - Implementers must also ensure that `relock` uses the same locking method as the original
|
||||
/// is owned, that is, between calls to [`lock`] and [`unlock`].
|
||||
/// - Implementers must also ensure that [`relock`] uses the same locking method as the original
|
||||
/// lock operation.
|
||||
///
|
||||
/// [`lock`]: Backend::lock
|
||||
/// [`unlock`]: Backend::unlock
|
||||
/// [`relock`]: Backend::relock
|
||||
pub unsafe trait Backend {
|
||||
/// The state required by the lock.
|
||||
type State;
|
||||
|
||||
/// The state required to be kept between `lock` and `unlock`.
|
||||
/// The state required to be kept between [`lock`] and [`unlock`].
|
||||
///
|
||||
/// [`lock`]: Backend::lock
|
||||
/// [`unlock`]: Backend::unlock
|
||||
type GuardState;
|
||||
|
||||
/// Initialises the lock.
|
||||
|
||||
Reference in New Issue
Block a user