rust/kernel/list/arc_field.rs
Source file repositories/reference/linux-study-clean/rust/kernel/list/arc_field.rs
File Facts
- System
- Linux kernel
- Corpus path
rust/kernel/list/arc_field.rs- Extension
.rs- Size
- 3474 bytes
- Lines
- 98
- Domain
- Rust Kernel Layer
- Bucket
- Rust API Membrane
- Inferred role
- Rust Kernel Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
Rust-side wrappers and abstractions around kernel C APIs, ownership contracts, allocation, synchronization, and module integration.
- Rust-side wrappers and abstractions around kernel C APIs, ownership contracts, allocation, synchronization, and module integration.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0
// Copyright (C) 2024 Google LLC.
//! A field that is exclusively owned by a [`ListArc`].
//!
//! This can be used to have reference counted struct where one of the reference counted pointers
//! has exclusive access to a field of the struct.
//!
//! [`ListArc`]: crate::list::ListArc
use core::cell::UnsafeCell;
/// A field owned by a specific [`ListArc`].
///
/// [`ListArc`]: crate::list::ListArc
pub struct ListArcField<T, const ID: u64 = 0> {
value: UnsafeCell<T>,
}
// SAFETY: If the inner type is thread-safe, then it's also okay for `ListArc` to be thread-safe.
unsafe impl<T: Send + Sync, const ID: u64> Send for ListArcField<T, ID> {}
// SAFETY: If the inner type is thread-safe, then it's also okay for `ListArc` to be thread-safe.
unsafe impl<T: Send + Sync, const ID: u64> Sync for ListArcField<T, ID> {}
impl<T, const ID: u64> ListArcField<T, ID> {
/// Creates a new `ListArcField`.
pub fn new(value: T) -> Self {
Self {
value: UnsafeCell::new(value),
}
}
/// Access the value when we have exclusive access to the `ListArcField`.
///
/// This allows access to the field using an `UniqueArc` instead of a `ListArc`.
pub fn get_mut(&mut self) -> &mut T {
self.value.get_mut()
}
/// Unsafely assert that you have shared access to the `ListArc` for this field.
///
/// # Safety
///
/// The caller must have shared access to the `ListArc<ID>` containing the struct with this
/// field for the duration of the returned reference.
pub unsafe fn assert_ref(&self) -> &T {
// SAFETY: The caller has shared access to the `ListArc`, so they also have shared access
// to this field.
unsafe { &*self.value.get() }
}
/// Unsafely assert that you have mutable access to the `ListArc` for this field.
///
/// # Safety
///
/// The caller must have mutable access to the `ListArc<ID>` containing the struct with this
/// field for the duration of the returned reference.
#[expect(clippy::mut_from_ref)]
pub unsafe fn assert_mut(&self) -> &mut T {
// SAFETY: The caller has exclusive access to the `ListArc`, so they also have exclusive
// access to this field.
unsafe { &mut *self.value.get() }
}
}
/// Defines getters for a [`ListArcField`].
#[macro_export]
#[doc(hidden)]
macro_rules! define_list_arc_field_getter {
($pub:vis fn $name:ident(&self $(<$id:tt>)?) -> &$typ:ty { $field:ident }
$($rest:tt)*
) => {
$pub fn $name<'a>(self: &'a $crate::list::ListArc<Self $(, $id)?>) -> &'a $typ {
let field = &(&**self).$field;
// SAFETY: We have a shared reference to the `ListArc`.
unsafe { $crate::list::ListArcField::<$typ $(, $id)?>::assert_ref(field) }
}
$crate::list::define_list_arc_field_getter!($($rest)*);
};
($pub:vis fn $name:ident(&mut self $(<$id:tt>)?) -> &mut $typ:ty { $field:ident }
$($rest:tt)*
) => {
$pub fn $name<'a>(self: &'a mut $crate::list::ListArc<Self $(, $id)?>) -> &'a mut $typ {
let field = &(&**self).$field;
// SAFETY: We have a mutable reference to the `ListArc`.
unsafe { $crate::list::ListArcField::<$typ $(, $id)?>::assert_mut(field) }
}
Annotation
- Atlas domain: Rust Kernel Layer / Rust API Membrane.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.