On Wed, May 27, 2026 at 08:31:44AM +0200, Philipp Stanner wrote: [..] > > > > > > > > > > > > > > > > > Compared to Alice's RcuBox proposal: > > > > > > > > > > > > > > > > > > https://lore.kernel.org/rust-for-linux/[email protected]/ > > > > > > > > > > > > I do have a design question: is support data type like > > > > > > Arc<CallBack<T>> > > > > > > or Pin<VBox<Callback<T>> in the plan of this API? If so, how would > > > > > > that > > > > > > be like? A separate new() and submit() function or a separate data > > > > > > type? > > > > > > > > > > I wasn't aware of Alice's proposal. Let me try whether I can make it > > > > > work for my purposes. > > > > > > > > > > The idea behind my code here would be to have some minimalist RCU > > > > > wrapper that merely defers dropping data. So it's a fire-and-forget > > > > > mechanism that would not support Arc: take over ownership of the data, > > > > > have it be unaccessible, and drop it after a grace period. > > > > > > > > > > > > > Maybe then name this data structure `RcuDeferDropBox<T>` or something? > > > > Because if the design goal is not to support a general RCU usage (with > > > > readers), than it probably shouldn't take the rcu::Callback name. > > > > > > > > Or maybe keep the `Callback<T>`, but only implement `new()` (with a > > > > return type as `impl PinInit<Callback<T>>` and the rcu_head accessor of > > > > it. Then based on it you can implement the `RcuDeferDropBox<T>`, in this > > > > way, we could both support your usage and move towards a full-featured > > > > RCU implementation. Thoughts? > > > > > > > > Plus, I think Alice's patch here [1] would also benefit from having a > > > > basic rcu::Callback (to replace `PollCondVarBoxInner`). > > > > > > > > [1]: > > > > https://lore.kernel.org/rust-for-linux/[email protected]/ > > > > > > My patch specifically uses kvfree_call_rcu(), which I think is important > > > that it keeps using over call_rcu(). > > > > > > > Of course, but note that using call_rcu() for your case was not my > > suggestion. We can reuse a general `Callback<T>` which is not tied to > > call_rcu() or kvfree_call_rcu() to represent a container type with a > > rcu_head for both cases (your and Philipp's). > > I have given Alice's code a spin and concluded that it would be fully > usable for my intended use-case. The trick would then be to force users > of my API to pass their data in an RcuBox, which Rust can certainly
Note that we can extend RcuBox to implement `InPlaceInit` similar as a normal Box, that way you can ask user to pass the `impl PinInit<T>` instead of the data. > enforce. Has the great advantage of me not having to allocate again > just to drop something, so this is a far cleaner design. > > From my side, only minor details would remain open regarding Alice's > draft, like Boqun's question about how to implement VBox maybe. > I think we can make RcuBox generic over Allocator, i.e. `RcuBox<T, A: Allocator>` then we should be able to support vmalloc as well. Regards, Boqun > But in principle you can regard my patch here to be withdrawn :) > > Regards > P. > > > > > Regards, > > Boqun > > > > > Alice >
