On Sat, Dec 13 2025, Alexander Graf wrote: > Hi Pratyush, > > On 10.12.25 20:26, Pratyush Yadav wrote: >> As live update evolves, there will be a need to update the serialization >> formats for the different file types. This could be for adding new >> features, for supporting a change in behaviour, or to fix bugs. >> >> If the current kernel does not understand the same set of versions as >> the next kernel, live update will inevitably fail. The next kernel will >> be unable to understand the handed over data and will be unable to >> restore memory, devices, IOMMU page tables, etc. >> >> List the set of versions the kernel understands in a section in vmlinux. >> This can then be used by userspace tooling to make sure the set of file >> descriptors it uses have the same version between both kernels. If there >> is a mismatch, the tooling can catch this early and abort live update >> before it is too late. >> >> The versions are listed in a section called ".liveupdate_versions". The >> section has a header that contains a magic number and the version of the >> data format. The list of version strings directly follow this header. >> Only the version strings are listed, and it is up to userspace to map >> them to file descriptor types. >> >> The format of the section has the same ABI rules as the rest of LUO ABI. >> >> Introduce a LIVEUPDATE_FILE_HANDLER macro that makes it easy to define a >> file handler while also adding its version string to the right section. >> >> Signed-off-by: Pratyush Yadav <[email protected]> > > To support multi-version preservation and resume, how about you add a > "profile" > hint to the handlers? Then you can tag the handlers with "current" and a > "previous". You then expose one section table with supported versions per > profile. And that means you can from user space select the local profile to > serialize and match that against the target profile of the target system. > > It also allows you to support more "profiles", such as elaborate downstream > version combinations, that upstream will not have to care about.
So in essence you want to tie the versions into a "version set"? If you want to use a new version even for one component, you would create a new version set. Interesting idea, but I am curious. Do you see a reason for grouping versions together in this fashion? Why not let each version be changed independently? -- Regards, Pratyush Yadav
