On Wed, Jun 3, 2026 at 11:33 AM Philipp Stanner phasta@mailbox.org wrote:
On Mon, 2026-06-01 at 06:41 -0700, Boqun Feng wrote:
On Mon, Jun 01, 2026 at 09:56:23AM +0200, Philipp Stanner wrote:
On Sat, 2026-05-30 at 08:08 -0700, Boqun Feng wrote:
On Sat, May 30, 2026 at 04:35:10PM +0200, Philipp Stanner wrote:
From: Alice Ryhl aliceryhl@google.com
This adds an RcuBox container, which is like KBox except that the value is freed with kfree_rcu.
To allow containers to rely on the rcu properties of RcuBox, an extension of ForeignOwnable is added.
Signed-off-by: Alice Ryhl aliceryhl@google.com
I have the following on top of Alice's patch. @Alice, @Danilo, thoughts?
Then we can have:
type RcuKBox<T> = RcuBox<T, Kmalloc>; type RcuVBox<T> = RcuBox<T, Vmalloc>;
No objections by me.
I just think we have to decide how the treat the namespaces, though. Probably Alice wrote it like that so that it's very apparent that this is not a normal box. It still breaks the naming convention in my opinion.
rcu::Box vs rcu::RcuBox
With all other subsystems, naming like that seems not allowed.
dma::Fence vs dma::DmaFence
I probably would allow the user to decide whether he wants to just use it as `rcu::Box` in all his code.
But no hard feelings.
For this I think that rcu::RcuBox is a bit different than dma::Fence, because Box has its widely-accepted meaning through all Rust code, while `Fence` doesn't. Hence my current thought is rcu::RcuBox and dma::Fence. My personal preference is using namespace as much as we could until there might be some misleading.
Yoah, probably better we're safer rather than hyper-consistent.
and Philipp can use the `RcuKBox` in this patchset. We also need to impl InPlaceInit for RcuBox, but that can be added later.
So shall we merge my series with Alice's patch, and later we add your patch and other features, or would you prefer to have the additional boxes from your patch from the get-go?
I would like to have it from the get-go mainly because of RcuBox vs RcuKBox naming. Thank you!
Fine by me. Just process-wise: how should we do it?
I could include your patch on top of Alice's. Would be a bit more consistent regarding the git-workflow if we'd squash the two patches, but then you two would have to agree on authorship.
All is fine by me, but I wanted to ask instead of just do A or B.
Squashing is fine with me, thanks.
Alice