From: tarunsahu@google.com
To: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
Andrew Morton <akpm@linux-foundation.org>,
joro@8bytes.org, Pratyush Yadav <pratyush@kernel.org>,
maz@kernel.org, arnd@arndb.de,
David Matlack <dmatlack@google.com>,
jgg@nvidia.com, robin.murphy@arm.com, loganodell@google.com,
oupton@kernel.org, kevin.tian@intel.com, alex@shazbot.org,
dwmw2@infradead.org, pbonzini@redhat.com, seanjc@google.com,
will@kernel.org, Alexander Graf <graf@amazon.com>,
Bjorn Helgaas <bhelgaas@google.com>,
baolu.lu@linux.intel.com, linux-arm-kernel@lists.infradead.org,
linux-arch@vger.kernel.org, sagis@google.com,
linux-mm@kvack.org, kvmarm@lists.linux.dev,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
kexec@lists.infradead.org, skhawaja@google.com,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/4] liveupdate: Rename handler compatible to name
Date: Fri, 23 Oct 2026 21:51:51 +0000 [thread overview]
Message-ID: <9huz33twf5l4.fsf@tarunix.c.googlers.com> (raw)
In-Reply-To: <atsQQcUiVhb9KXWZ@kernel.org>
Mike Rapoport <rppt@kernel.org> writes:
> 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:
>> >> >>
>> >> >> --- a/include/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.
Okay.
I will send the v3 soon with feature flags only. Also I will drop this
and its next patch, as It will be part of other compatiblity series with
exporting the schema to userspace so that userspace can make better
decision in selecting the handler (As per the response from the other thread).
~Tarun
>
> --
> Sincerely yours,
> Mike.
next prev parent reply other threads:[~2026-10-23 21:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 15:25 [RFC PATCH v2 0/4] liveupdate: Feature header ABI and named handler Tarun Sahu
2026-10-21 15:25 ` [RFC PATCH v2 1/4] liveupdate: Rename handler compatible to name Tarun Sahu
2026-10-21 17:11 ` Pasha Tatashin
2026-10-21 18:16 ` tarunsahu
2026-10-21 19:11 ` Pasha Tatashin
2026-10-21 19:35 ` tarunsahu
2026-10-23 7:44 ` Mike Rapoport
2026-10-23 21:51 ` tarunsahu [this message]
2026-10-21 15:25 ` [RFC PATCH v2 2/4] liveupdate: Select file handler by name in the preserve ioctl Tarun Sahu
2026-10-21 17:17 ` Pasha Tatashin
2026-10-21 23:02 ` David Matlack
2026-10-22 1:14 ` Pasha Tatashin
2026-10-22 17:57 ` David Matlack
2026-10-22 12:50 ` tarunsahu
2026-10-22 13:42 ` Pasha Tatashin
2026-10-21 15:25 ` [RFC PATCH v2 3/4] liveupdate: Replace compatibility string with a 2-bit pair feature header Tarun Sahu
2026-10-21 17:27 ` Pasha Tatashin
2026-10-21 17:40 ` Jason Gunthorpe
2026-10-21 17:55 ` Pasha Tatashin
2026-10-21 18:40 ` tarunsahu
2026-10-21 18:46 ` David Matlack
2026-10-21 18:50 ` Pasha Tatashin
2026-10-21 23:28 ` David Matlack
2026-10-22 1:26 ` Pasha Tatashin
2026-10-22 2:57 ` David Matlack
2026-10-22 3:32 ` Pasha Tatashin
2026-10-22 3:52 ` David Matlack
2026-10-22 4:11 ` Pasha Tatashin
2026-10-22 17:51 ` David Matlack
2026-10-22 20:53 ` Pasha Tatashin
2026-10-23 13:50 ` David Matlack
2026-10-21 23:55 ` David Matlack
2026-10-22 0:04 ` David Matlack
2026-10-21 15:25 ` [RFC PATCH v2 4/4] mm: memfd_luo: Add the " Tarun Sahu
2026-10-21 17:38 ` Pasha Tatashin
2026-10-21 23:18 ` David Matlack
2026-10-22 0:41 ` Pasha Tatashin
2026-10-22 2:51 ` David Matlack
2026-10-22 3:50 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9huz33twf5l4.fsf@tarunix.c.googlers.com \
--to=tarunsahu@google.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=arnd@arndb.de \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dmatlack@google.com \
--cc=dwmw2@infradead.org \
--cc=graf@amazon.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=loganodell@google.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=skhawaja@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®