Re: [RFC PATCH 0/3] liveupdate: Move to feature flags for LUO and memfd ABI compatibility

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Sep 10, 2026 at 09:27:58PM +0000, David Matlack wrote:
> Each ABI is now extensible with a set of structured featured flags that
> are exposed to userspace. Userspace can inspect the flags that the
> kernel supports and confirm the next kernel also supports them.

I'm fine with that bit, it is really just a different way to encode an
ABI ID #. If ABI 5 is spelled b11111 instead it doesn't materially
change how things work.

It was always the case you can use the same struct extension techinque
with a version number. A version can't handle 'holes' in the feature
mask, but I haven't thought that was a meaningful use case.

"if (id > 10)" instead "if (id & FEAT)" isn't a big coding difference.

My concern is the implied position that the kernel must make full use
of this to maximize compatability or bust. That's what has always
concerned me about all these proposals since the start.

I do not want to have arguments upstream about not changing things
because we didn't do a perfect job preserving luo compatability with
upgrade and downgrade for arbitary kernel versions. That has always
been my position and worry.

So, change the simple version to a u64 features[] tuple (be sure to
use an array, we will need alot of them!!) and I'm fine. But I'm not
going to promise that every upstream kernel will strictly only have an
increasing string of 1's. You are going to get some that look like
b1110000 and still wont work with old kernels.

Sean's initial email was asking for strict never-break ABI
compatability rules on top, and that is what I've been reacting to.

Jason