[RFC v1 0/9] kho: granular compatibility and header decoupling
Pasha Tatashin
pasha.tatashin at soleen.com
Mon Jun 8 18:14:53 PDT 2026
On 06-08 21:11, Mike Rapoport wrote:
> 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
Agreed. I'll also pay closer attention to the documentation.
> - I'm fine with abi/vmalloc.h, presuming KHOSER_PTR() is not part of it
Yes, I will move KHOSER_PTR() to the shared compat.h in v2 so it's not
tied to vmalloc.
> - I can live with kho_vmalloc.c although I still consider it unnecessary
> churn
Appreciate it.
> - 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.
That is a very reasonable compromise. I am fine with keeping the
consumer-facing function declarations in kexec_handover.h so they remain
grouped with folios and pages.
> > 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.
Agreed.
Thanks!
Pasha
More information about the kexec
mailing list