Re: [RFC PATCH] liveupdate: list all file handler versions in vmlinux section

[Pratyush Yadav <pratyush@kernel.org>]

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 <pratyush@kernel.org>
>
> 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