[RFC PATCH v2 3/4] liveupdate: Replace compatibility string with a 2-bit pair feature header

[Pratyush Yadav]

On Mon, Oct 26 2026, David Matlack wrote:

> On 2026-10-25 04:38 PM, Pasha Tatashin wrote:
>> On Fri, Oct 23, 2026 at 9:50 AM David Matlack <dmatlack at google.com> wrote:
>
[...]
>> The reason I care about keeping the header compact is that we are
>> defining a foundational kernel ABI and want to use this header across
>> almost every serialized data structure so we can evolve them later
>> without breaking compatibility. While some top-level structs are on
>> sparse folios today, other serialized structs are tightly packed, and
>> we are looking to add KHO slab support in the future where tightly
>> packed allocations will be common.
>
> My intuition is we will have a small number of headers per preserved
> file and per preserved FLB. One for the top-level struct and then
> optionally a few more for sub-structs like arch-specific data. That is
> why I am less worried 8 bytes per header, even if we fix the folio
> problem.
>
> Maybe where our visions differ is when there are collections of
> serialized structs, like KHO blocks. For collections I don't think the
> elements will each have their own headers. Otherwise the elements could
> be different sizes.

kho_block today doesn't store entry_size in the serialized payload. It
relies on its caller to do so. With extensible structures, this can get
messy. Sure, the owner of the kho_block_set can track the size somewhere
in its payload, but perhaps we should store the size in
kho_block_header_ser to begin with?

Anyway, not a problem this series needs to solve, but something we
should eventually do.

[...]

-- 
Regards,
Pratyush Yadav