On Fri, 05 Jun 2026 03:32:26 +0000, Pasha Tatashin <[email protected]> wrote:
Hi, > [...] > data structure. Keeping all of this within the same `kexec_handover.c` > file, and also under the same global version, is no longer sustainable. > > To address this, this series: > 1. Refactors and reorganizes the code by splitting out radix tree > and vmalloc into separate files. I'd keep vmalloc where it is, it's more of a memory preservation primitive rather than a data structure of it's own. The data structure it uses is an implementation detail. Let's minimize the churn where possible for the sake of git blame and backports. > 2. Moves and organizes internal and ABI headers into structured > directories under include/linux/kho/ and include/linux/kho/abi/. > Instead of cluttering include/linux/ with prefix-styled headers like > kho_block.h or kho_radix_tree.h, we use the already existing > include/linux/kho/ directory (e.g., kho/block.h and > kho/radix_tree.h). This looks to me like unnecessary churn. These all are bundled with KHO anyway, there is no header dependencies that justify small headers for each two functions and netiher linux/kexec_handover.h nor linux/kho/abi/kexec_handover.h are that long to start splitting them. > 3. Introduces a standard set of compatibility helpers in > kho/abi/compat.h. > 4. Decouples the compatibility strings of individual KHO subsystems > (radix tree, vmalloc, and block) from the global KHO version. > This enables independent, granular compatibility versioning. I agree that we should decouple versioning of these components from the global KHO versioning. Can't say I agree with the way you propose to do it. I don't like that each user of a KHO component should include that component version in its own version string (or whatever it may become later). It requires ABI headers update each time a user decides to add a new data structure and worse when there is a change to that data structure. It creates coupling of the data structure user with its particular version and just looks ugly IMHO. Suppose we added new fields to vmalloc, but made the implementation of restore to be able to cope with both old and new versions. How this would be reflected in memfd versioning? We'll add both versions of vmalloc to memfd version? And all other vmalloc users? Or, say, we add support to kmalloc() and use it in kho_block. Then we'd have to add kmalloc() versioning to all kho_block users, right? I think the versioning of each component should be handled by ->restore() of that component. If it sees an incompatible version in the preserved data, it returns an error. The versions can be stored e.g. in the base KHO fdt. > 5. Adds a KUnit test suite to verify that the composite compatibility > strings of different subsystems remain unique and sorted in > alphabetical order, guaranteeing a consistent and predictable > representation across configurations. Without "composite compatibility strings" we don't need to care about them "remaining unique and sorted in alphabetical order". The need for this test alone is already a red flag ;-) -- Sincerely yours, Mike.
