On Mon, Sep 01, 2025 at 07:10:53PM +0200, Pratyush Yadav wrote: > Building kvalloc on top of this becomes trivial. > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/pratyush/linux.git/commit/?h=kho-array&id=cf4c04c1e9ac854e3297018ad6dada17c54a59af This isn't really an array, it is a non-seekable serialization of key/values with some optimization for consecutive keys. IMHO it is most useful if you don't know the size of the thing you want to serialize in advance since it has a nice dynamic append. But if you do know the size, I think it makes more sense just to do a preserving vmalloc and write out a linear array.. So, it could be useful, but I wouldn't use it for memfd, the vmalloc approach is better and we shouldn't optimize for sparsness which should never happen. > > The versioning should be first class, not hidden away as some emergent > > property of registering multiple serializers or something like that. > > That makes sense. How about some simple changes to the LUO interfaces to > make the version more prominent: > > int (*prepare)(struct liveupdate_file_handler *handler, > struct file *file, u64 *data, char **compatible); Yeah, something more integrated with the ops is better. You could list the supported versions in the ops itself const char **supported_deserialize_versions; And let the luo framework find the right versions. But for prepare I would expect an inbetween object: int (*prepare)(struct liveupdate_file_handler *handler, struct luo_object *obj, struct file *file); And then you'd do function calls on 'obj' to store 'data' per version. Jason
