Messages in this thread |  | | Subject | Re: [PATCH v4 2/2] rust: zpool: add abstraction for zpool drivers | | From | Vitaly Wool <> | | Date | Wed, 27 Aug 2025 16:24:08 +0200 |
| |
> On Aug 26, 2025, at 7:02 PM, Benno Lossin <lossin@kernel.org> wrote: > > On Sat Aug 23, 2025 at 3:05 PM CEST, Vitaly Wool wrote: >> +pub trait ZpoolDriver { >> + /// Opaque Rust representation of `struct zpool`. >> + type Pool: ForeignOwnable; > > I think this is the same question that Danilo asked a few versions ago, > but why do we need this? Why can't we just use `Self` instead?
It’s convenient to use it in the backend implementation, like in the toy example supplied in the documentation part:
+/// struct MyZpool { +/// name: &'static CStr, +/// bytes_used: AtomicU64, +/// } … +/// impl ZpoolDriver for MyZpoolDriver { +/// type Pool = KBox<MyZpool>;
Does that make sense? > >> + >> + /// Create a pool. >> + fn create(name: &'static CStr, gfp: Flags) -> Result<Self::Pool>; >> + >> + /// Destroy the pool. >> + fn destroy(pool: Self::Pool); > > This should just be done via the normal `Drop` trait?
Let me check if I’m getting you right here. I take what you are suggesting is that we require that Pool implements Drop trait and then just do something like:
extern "C" fn destroy_(pool: *mut c_void) { // SAFETY: The pointer originates from an `into_foreign` call. unsafe { drop(T::Pool::from_foreign(pool)) } }
Is that understanding correct?
~Vitaly
> > --- > Cheers, > Benno > >> + >> + /// Allocate an object of size `size` bytes from `pool`, with the allocation flags `gfp` and >> + /// preferred NUMA node `nid`. If the allocation is successful, an opaque handle is returned. >> + fn malloc( >> + pool: <Self::Pool as ForeignOwnable>::BorrowedMut<'_>, >> + size: usize, >> + gfp: Flags, >> + nid: NumaNode, >> + ) -> Result<usize>; >
|  |