On Thu, Sep 18, 2025 at 09:00:31PM +0200, Andrey Ryabinin wrote: > By contrast, KSTATE centralizes this logic. It avoids duplicating code > and lets us express the preservation details declaratively instead > of re-implementing them per struct.
I didn't really see it centralize much of anything, it is just a long way to spell "memcpy" the way it is being shown here. I'm all for consolidating, but please do actually show some consolidation.. > On the versioning side: > With this approach, introducing a new ABI version (say, abi_map_v1) > would require us to maintain restore logic for each supported version, > and carefully handle upgrades between them. Yes, you MUST do this. It cannot be magically avoided. > With KSTATE, versioning is built in. For example, adding a new field can > simply be expressed as: No, it isn't. The code still has to process versions and still has to understand what to do when the unpacked struct didn't have its fields written. If anything it is making it more obfuscated and complicated to tell if the comparability is done correctly or not. Jason
