Holding C Reference-Counted Objects with ARef
Many kernel objects, a device or a file among them, already carry their own reference count managed by C functions that raise and lower it. Rust models this with a trait saying an object is always reference counted and a smart pointer that takes a reference when cloned and drops it when it goes out of scope. You use it whenever you want to keep a kernel object alive longer than the callback that handed it to you. In C, the matching bug is forgetting the release call on one error path, leaking the object forever, or forgetting the acquire and having it freed underneath you.
Questions this Concept answers
- What is the essential difference between holding a kernel object in an `ARef` and holding data in a kernel `Arc`?
This Concept is waiting for its first lesson!
Many kernel objects, a device or a file among them, already carry their own reference count managed by C functions that raise and lower it. Rust models this with a trait saying an object is always reference counted and a smart pointer that takes a reference when cloned and drops it when it goes out of scope. You use it whenever you want to keep a kernel object alive longer than the callback that handed it to you. In C, the matching bug is forgetting the release call on one error path, leaking the object forever, or forgetting the acquire and having it freed underneath you.
Are you a teacher? Sign in to start contributing.
Sign In