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
