On Mon, Jun 08, 2026 at 04:12:56PM +0000, Pasha Tatashin wrote:
> On 06-08 13:26, Mike Rapoport wrote:
> > On 2026-06-07 13:43:09+00:00, Pasha Tatashin wrote:
>
> Keeping all of that in a single KHO file is the wrong approach and goes
> against how other logically separated subsystems in Linux are organized
> (e.g., mm/vmap.c, mm/vmalloc.c, etc.). Yes, there are some messier
> places in the kernel as well, but keeping this in its own dedicated
> kho_vmalloc.c file makes complete sense to me.
Either I hallucinated or b4 ate a paragraph from my reply ;)
Regarding the code movement
- splitting radix tree makes perfect sense to me, just the documentation
part needs more care than mechanical move
- I'm fine with abi/vmalloc.h, presuming KHOSER_PTR() is not part of it
- I can live with kho_vmalloc.c although I still consider it unnecessary
churn
- I'm against moving vmalloc APIs from kexec_handover.h because they are
very close in nature to folio and pages. I don't see core KHO as
responsible for preserving physically contiguous ranges but rather as
preserving allocations. Not sure we'll ever support kmalloc(), but still.
> However, overall enforcing the use of KHOSER is unrelated to this work.
> I have my own thoughts on this, and perhaps with proper versioning,
> using KHOSER_PTR everywhere would be appropriate, but let's keep that as
> a separate work.
This is a separate work, indeed. But regardless of the versioning it's
already better than plain u64 because it provides type safety.
> > Actually FDT "compatible" handles versioning nicer than composite strings
> > You can have
> >
> > compatible="kho-v4", "vmalloc-v1", "radix-v1", "block-v2";
> >
> > and check fdt_node_check_compatible("vmalloc-v1") for vmalloc and
> > fdt_node_check_compatible("block-v2") for block.
>
> That is actually very similar to what I am proposing—individual version
> tokens (which in my current series are concatenated into a composite
> compatibility string separated by ';').
Yes, you reinvented the wheel :-P
The difference between FDT-compatible and the composite strings is that the
strings are all or nothing while FDT is "any of".
But that's only a side note, we're not going to use fdt-compatible.
> But let's not get too fixated on the composite string formatting. I
> actually really like what you are proposing: using integers for versions
> and having each registered component carry its own "NAME" and version
> number in the KHO FDT.
Yeah, something like that.
> Pasha
--
Sincerely yours,
Mike.
