rust/kernel/gpu/buddy.rs
Source file repositories/reference/linux-study-clean/rust/kernel/gpu/buddy.rs
File Facts
- System
- Linux kernel
- Corpus path
rust/kernel/gpu/buddy.rs- Extension
.rs- Size
- 19683 bytes
- Lines
- 615
- 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
struct GpuBuddyInnerfunction Rangefunction to_resultfunction drop
Annotated Snippet
struct GpuBuddyInner {
#[pin]
inner: Opaque<bindings::gpu_buddy>,
// TODO: Replace `Mutex<()>` with `Mutex<Opaque<..>>` once `Mutex::new()`
// accepts `impl PinInit<T>`.
#[pin]
lock: Mutex<()>,
/// Cached creation parameters (do not change after init).
params: GpuBuddyParams,
}
impl GpuBuddyInner {
/// Create a pin-initializer for the buddy allocator.
fn new(params: GpuBuddyParams) -> impl PinInit<Self, Error> {
let size = params.size;
let chunk_size = params.chunk_size;
// INVARIANT: `gpu_buddy_init` returns 0 on success, at which point the
// `gpu_buddy` structure is initialized and ready for use with all
// `gpu_buddy_*` APIs. `try_pin_init!` only completes if all fields succeed,
// so the invariant holds when construction finishes.
try_pin_init!(Self {
inner <- Opaque::try_ffi_init(|ptr| {
// SAFETY: `ptr` points to valid uninitialized memory from the pin-init
// infrastructure. `gpu_buddy_init` will initialize the structure.
to_result(unsafe {
bindings::gpu_buddy_init(ptr, size, chunk_size.as_usize() as u64)
})
}),
lock <- new_mutex!(()),
params,
})
}
/// Lock the mutex and return a guard for accessing the allocator.
fn lock(&self) -> GpuBuddyGuard<'_> {
GpuBuddyGuard {
inner: self,
_guard: self.lock.lock(),
}
}
}
#[pinned_drop]
impl PinnedDrop for GpuBuddyInner {
fn drop(self: Pin<&mut Self>) {
let guard = self.lock();
// SAFETY: Per the type invariant, `inner` contains an initialized
// allocator. `guard` provides exclusive access.
unsafe { bindings::gpu_buddy_fini(guard.as_raw()) };
}
}
// SAFETY: `GpuBuddyInner` can be sent between threads.
unsafe impl Send for GpuBuddyInner {}
// SAFETY: `GpuBuddyInner` is `Sync` because `GpuBuddyInner::lock`
// serializes all access to the C allocator, preventing data races.
unsafe impl Sync for GpuBuddyInner {}
/// Guard that proves the lock is held, enabling access to the allocator.
///
/// The `_guard` holds the lock for the duration of this guard's lifetime.
struct GpuBuddyGuard<'a> {
inner: &'a GpuBuddyInner,
_guard: MutexGuard<'a, ()>,
}
impl GpuBuddyGuard<'_> {
/// Get a raw pointer to the underlying C `gpu_buddy` structure.
fn as_raw(&self) -> *mut bindings::gpu_buddy {
self.inner.inner.get()
}
}
/// GPU buddy allocator instance.
///
/// This structure wraps the C `gpu_buddy` allocator using reference counting.
/// The allocator is automatically cleaned up when all references are dropped.
///
/// Refer to the module-level documentation for usage examples.
pub struct GpuBuddy(Arc<GpuBuddyInner>);
impl GpuBuddy {
/// Create a new buddy allocator.
///
/// The allocator manages a contiguous address space of the given size, with the
/// specified minimum allocation unit (chunk_size must be at least 4KB).
Annotation
- Detected declarations: `struct GpuBuddyInner`, `function Range`, `function to_result`, `function drop`.
- 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.