On Wed, Jun 3, 2026 at 11:33 AM Philipp Stanner <[email protected]> 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 <[email protected]> > > > > > > > > > > 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 <[email protected]> > > > > > --- > > > > > > > > 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
