[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0727b5a1-078f-0055-fc52-61b80bc5d59e@gentwo.org>
Date: Wed, 14 Jan 2026 16:46:04 -0800 (PST)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Al Viro <viro@...iv.linux.org.uk>
cc: linux-mm@...ck.org, Vlastimil Babka <vbabka@...e.cz>,
Harry Yoo <harry.yoo@...cle.com>, linux-fsdevel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Mateusz Guzik <mguzik@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/15] kmem_cache instances with static storage
duration
On Sat, 10 Jan 2026, Al Viro wrote:
> 1) as it is, struct kmem_cache is opaque for anything outside of a few
> files in mm/*; that avoids serious headache with header dependencies,
> etc., and it's not something we want to lose. Solution: struct
> kmem_cache_opaque, with the size and alignment identical to struct
> kmem_cache. Calculation of size and alignment can be done via the same
> mechanism we use for asm-offsets.h and rq-offsets.h, with build-time
> check for mismatches. With that done, we get an opaque type defined in
> linux/slab-static.h that can be used for declaring those caches.
> In linux/slab.h we add a forward declaration of kmem_cache_opaque +
> helper (to_kmem_cache()) converting a pointer to kmem_cache_opaque
> into pointer to kmem_cache.
Hmmm. A new kernel infrastructure feature: Opaque objects
Would that an deserve a separate abstraction so it is usable by other
subsystems?
Powered by blists - more mailing lists