On Wed, Jun 03, 2026 at 12:05:04PM +0000, Pasha Tatashin wrote: > On 06-03 09:49, Mike Rapoport wrote: > > On Wed, 03 Jun 2026 03:28:58 +0000, Pasha Tatashin > > <[email protected]> wrote: > > > diff --git a/include/linux/kho/abi/block.h b/include/linux/kho/abi/block.h > > > new file mode 100644 > > > index 000000000000..8641c20b379b > > > --- /dev/null > > > +++ b/include/linux/kho/abi/block.h > > > @@ -0,0 +1,56 @@ > > > [ ... skip 25 lines ... ] > > > +#define _LINUX_KHO_ABI_BLOCK_H > > > + > > > +#include <asm/page.h> > > > +#include <linux/types.h> > > > + > > > +#define KHO_BLOCK_ABI_COMPATIBLE "kho-block-v1" > > > > It's never used by block set and after looking at the following patches I > > found that it's appended to LUO compatible string. > > > > While this works for LUO, I think it should be kho_block_set_restore() > > responsibility to verify the compatibility. > > It should work for any component that relies on kho_block. My proposal > is to use this method for other common KHO data structures (e.g., kho > vmalloc, kho radix, future kho xarray). There is no need for them to > carry the compatibility string in their metadata, as whoever uses them > will include their compatibility string.
So if, say, memfd_luo uses kho vmalloc, xarray and blocks it'll have five compatibility strings glued together? > For now, reviewers will have to make sure that if the ABI header content > is changed, the compatibility string is updated. -- Sincerely yours, Mike.
