Re: [RFC PATCH v2 1/4] liveupdate: Rename handler compatible to name

[Mike Rapoport <rppt@kernel.org>]

On Wed, Oct 21, 2026 at 07:35:28PM +0000, tarunsahu@google.com wrote:
> Pasha Tatashin <pasha.tatashin@soleen.com> writes:
> > On Wed, Oct 21, 2026 at 2:16 PM <tarunsahu@google.com> wrote:
> >> Pasha Tatashin <pasha.tatashin@soleen.com> writes:
> >>
> >> > On Wed, Oct 21, 2026 at 11:25 AM Tarun Sahu <tarunsahu@google.com> wrote:
> >> >>
> >> >> File handler and File-Lifecycle-Bound (FLB) identifiers name the
> >> >
> >> > Please use FLB directly, no need to spell it out.
> >> >
> >> >> registered handler or FLB rather than a monolithic compatibility version.
> >> >> Rename compatible to name across LUO headers, structures, and consumers:
> >> >> - struct liveupdate_file_handler and struct luo_file_ser name field
> >> >> - LIVEUPDATE_HNDL_NAME_LENGTH (in include/uapi/linux/liveupdate.h) and
> >> >>   MEMFD_LUO_FH_NAME
> >> >> - struct liveupdate_flb name field, LIVEUPDATE_FLB_NAME_LENGTH,
> >> >>   PCI_LUO_FLB_NAME, and LIVEUPDATE_TEST_FLB_NAME
> >> >>
> >> >> Signed-off-by: Tarun Sahu <tarunsahu@google.com>
> >> >> ---
> >> >>  drivers/pci/liveupdate.c        | 10 ++++----
> >> >>  include/linux/kho/abi/luo.h     | 26 +++++++++----------
> >> >>  include/linux/kho/abi/memfd.h   |  4 +--
> >> >>  include/linux/kho/abi/pci.h     |  2 +-
> >> >>  include/linux/liveupdate.h      | 18 +++++--------
> >> >>  include/uapi/linux/liveupdate.h |  3 +++
> >> >>  kernel/liveupdate/luo_file.c    | 45 +++++++++++++++++----------------
> >> >>  kernel/liveupdate/luo_flb.c     | 16 ++++++------
> >> >>  lib/tests/liveupdate.c          | 22 ++++++++--------
> >> >>  mm/memfd_luo.c                  |  2 +-
> >> >>  10 files changed, 73 insertions(+), 75 deletions(-)
> >> >>
> >> >> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> >> >> index 51695782ed42..3cf01d7d615c 100644
> >> >> --- a/drivers/pci/liveupdate.c
> >> >> +++ b/drivers/pci/liveupdate.c
> >> >> @@ -424,7 +424,7 @@ static struct liveupdate_flb_ops pci_liveupdate_flb_ops = {
> >> >>
> >> >>  static struct liveupdate_flb pci_liveupdate_flb = {
> >> >>         .ops = &pci_liveupdate_flb_ops,
> >> >> -       .compatible = PCI_LUO_FLB_COMPATIBLE,
> >> >> +       .name = PCI_LUO_FLB_NAME,
> >> >>  };
> >> >>
> >> >>  static void pci_liveupdate_flb_put_outgoing(void)
> >> >> @@ -667,13 +667,13 @@ static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void)
> >> >>
> >> >>         /*
> >> >>          * Live Update is enabled and there is incoming FLB data, but none of it
> >> >> -        * matches pci_liveupdate_flb.compatible.
> >> >> +        * matches pci_liveupdate_flb.name.
> >> >>          */
> >> >>         if (ret == -ENOENT)
> >> >>                 return NULL;
> >> >>
> >> >>         /*
> >> >> -        * There is incoming FLB data that matches pci_liveupdate_flb.compatible
> >> >> +        * There is incoming FLB data that matches pci_liveupdate_flb.name
> >> >>          * but retrieve failed (pci_flb_retrieve() returned an error or LUO
> >> >>          * failed to acquire a reference to pci_liveupdate_flb_ops.owner).
> >> >>          */
> >> >> @@ -998,7 +998,7 @@ EXPORT_SYMBOL_GPL(pci_liveupdate_is_incoming);
> >> >>   */
> >> >>  int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
> >> >>  {
> >> >> -       pr_debug("Registering file handler \"%s\"\n", fh->compatible);
> >> >> +       pr_debug("Registering file handler \"%s\"\n", fh->name);
> >> >>         return liveupdate_register_flb(fh, &pci_liveupdate_flb);
> >> >>  }
> >> >>  EXPORT_SYMBOL_GPL(pci_liveupdate_register_flb);
> >> >> @@ -1009,7 +1009,7 @@ EXPORT_SYMBOL_GPL(pci_liveupdate_register_flb);
> >> >>   */
> >> >>  void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh)
> >> >>  {
> >> >> -       pr_debug("Unregistering file handler \"%s\"\n", fh->compatible);
> >> >> +       pr_debug("Unregistering file handler \"%s\"\n", fh->name);
> >> >>         liveupdate_unregister_flb(fh, &pci_liveupdate_flb);
> >> >>  }
> >> >>  EXPORT_SYMBOL_GPL(pci_liveupdate_unregister_flb);
> >> >> diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
> >> >> index 288076de6d4a..5fb2f46425d7 100644
> >> >> --- a/include/linux/kho/abi/luo.h
> >> >> +++ b/include/linux/kho/abi/luo.h
> >> >> @@ -39,9 +39,9 @@
> >> >>   *     Multiple blocks are linked via the `next` field in the header.
> >> >>   *
> >> >>   *   - struct luo_file_ser:
> >> >> - *     Metadata for a single preserved file. Contains the `compatible` string to
> >> >> - *     find the correct handler in the new kernel, a user-provided `token` for
> >> >> - *     identification, and an opaque `data` handle for the handler to use.
> >> >> + *     Metadata for a single preserved file. Contains the handler `name` string
> >> >> + *     to find the correct handler in the new kernel, a user-provided `token`
> >> >> + *     for identification, and an opaque `data` handle for the handler to use.
> >> >>   *
> >> >>   *   - struct luo_flb_header_ser:
> >> >>   *     Header for the FLB array. Contains the total page count of the
> >> >> @@ -49,9 +49,9 @@
> >> >>   *     that follow.
> >> >>   *
> >> >>   *   - struct luo_flb_ser:
> >> >> - *     Metadata for a single preserved global object. Contains its `name`
> >> >> - *     (compatible string), an opaque `data` handle, and the `count`
> >> >> - *     number of files depending on it.
> >> >> + *     Metadata for a single preserved global object. Contains its FLB `name`
> >> >> + *     string, an opaque `data` handle, and the `count` number of files
> >> >> + *     depending on it.
> >> >>   */
> >> >>
> >> >>  #ifndef _LINUX_KHO_ABI_LUO_H
> >> >> @@ -84,18 +84,16 @@ struct luo_ser {
> >> >>         u64 flbs_pa;
> >> >>  } __packed;
> >> >>
> >> >> -#define LIVEUPDATE_HNDL_COMPAT_LENGTH  48
> >> >> -
> >> >>  /**
> >> >>   * struct luo_file_ser - Represents the serialized preserves files.
> >> >> - * @compatible:  File handler compatible string.
> >> >> + * @name:        File handler name string.
> >> >
> >> > We are renaming from cpmaptible to name; I am not sure that is
> >> > necessary. We can still use compatible for the same purpose as name.
> >> > Unless it really bothers people, but for me 'compatible' works just
> >> > the same.
> >>
> >> Yes it is necessary, For example if we have two handler for a single
> >> subsystem. We should refer it by handle this or handler that, not like
> >> handler with compatible string this and handler with compatible string
> >> that.
> >
> > I still feel like compatability makes more sense to me. Take an example:
> >
> > We have two file handlers for memfd (i.e., FH_OLD and FH_NEW): one has
> > compatibility = "memfd", and the other has compatibility =
> > "memfd_next_generation". The user chooses one of them to preserve the
> > memfd data, and the compatibility string is saved alongside the FD.
> > When the next kernel scans through the registered file handlers, it
> > must find exactly one that is compatible with the preserved data.
> 
> I will open this for vote.

I'd rather won't ;-)

"compatible" does not contradict more fine grained bitfields, and still has meaning.
Just like in FDT world from where we inherited it, it means "these ops are
somewhat compatible with that serialized format, will check the details and
will know for sure".

And IMO we should keep it.
 
And please, trim your responses. I had to scroll 463 lines to see there's
nothing there.

-- 
Sincerely yours,
Mike.