From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.208.72 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792792315; b=kpOlmp1bppuMjRhHS9EM9HBWVzWBG8Wf2uVzD3+2VxzDe1JGN0bby032wJLHn37JH7KT s6sbrLv4YYTgS4TLwG9lhondA2iK6StGanmh12pg0CIqkFObYowGhDFIcQ+BIMNzYneAF 2v79hmdr/OUPNzQ7gwnn1Zmc8I6JMbJC/P+p3vCFt1Kio1xl6/vLU7WCKs/uEbSOgZW66 4SZc9zfW8BCUKoBmWfyNWVf3igfOYYsNV9wiHqgTbKpOzVpzM2cArbXMSrfJpMxtSTMmX jrklPAnyh74D89/YsYe0XH7RToHm5Anfd56Dc0+hYTf79w31HRE2r7k+ZRvrFcxnPEQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792792315; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Received:Date:In-Reply-To: Mime-Version:References:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; bh=37bgzHVD8y8sAVNI32vtF0/e4Mt+8V5lKNPa4buINEw=; b=5QzcOWtLvkRbZn8UZ9JcDgsWdR05aQb543/XuhMYKs8usNmQ7nTRAiKlD9znX7zKF/zK CqOfve1/icxyqVAJWG9Ks8p6HY/3+70KRzdk7qcgPhTPZ9J9g5moM03fM8aw3CpzY+MG+ wysTF41FsMgQ7Ivj9T2y8tn1/gWi2XHrOHQ3Kr1dAC+vS5bat3wfqMmumZBtL+sr5YxNo amDnQ5FNJCjpN79ymjaD5F+lVHq7QXZ94HE7rr/7P6N2umaLCg1swTRoq983ZGS7AWX0c MwQnqhtI9cFRf2thkfM+DLQPL58KEqztN8B3XG0/dFgWqIYNvcbT3qOQAUl8U75xw3A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--tarunsahu.bounces.google.com; dkim=pass header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20251104 header.b=hTQFFix8; arc=none smtp.remote-ip=209.85.208.72 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D488606A326 for ; Fri, 23 Oct 2026 21:51:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 4D488606A326 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tarunsahu.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20251104 header.b=hTQFFix8 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-6a125f5b317so1429355a12.1 for ; Fri, 23 Oct 2026 14:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1792792313; x=1793397113; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=37bgzHVD8y8sAVNI32vtF0/e4Mt+8V5lKNPa4buINEw=; b=hTQFFix8pn/Y3t4fncvPWkx+/E4dv1R+1G8m+PO1oOcB3UHZqMZlQsxwljO6bIWzBK ppASh7LU3KTalFg/FChHtssFZEKiew4d081cMUVJVpJ+paXaJUT5+XzAlutxkXjf0J8t Nly/LrQX47bht/9wdr/lSjgbzWtKvEDrZ7jujFjhT0L4t5DgH62d6ZeHQZdQczteFTSh 6LuwZ1uaBAAmjqeTmNy4ZAQwqzbnVIEGY6gYUyTFt/akgtqEYq/S7JyrJlSJeiQa9WHQ u6WAL02GRPtB5i1ATfv/EhHpS64FKP40MtYzKrtbprMfusiahYeHhLCxcwR0nIxAmp6G Ss+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792792313; x=1793397113; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=37bgzHVD8y8sAVNI32vtF0/e4Mt+8V5lKNPa4buINEw=; b=EWJnxE2zzjj/XO1nuvIuDSKdqgYFpQE6+y1tYSrTqar048h9vmfARchrAIGhShl+w7 pIMav69cN4nnL0OE4sCYkRsJFmRg3NNjzQ2koBu/2ce/bRPNvHMN5Wits4Qeeg8kZ55o hlO78bUIvL+omxX786uqGOKfCYe3EllsiXkdlOjKYf94JmeFUBOY4xxpNWFpEuE+Cc4r z4N4mr24zMGOUpdHowg1EynHbB41BfURAFyV+c8OSo5ZiKFs5az7b5r/xf00T3YhqLR5 HOHFAXI2U303hikxpvIqPGGNWqPoG9fNYpJ256Uf0M7Lp/0bNgRGUkHSB078ndZr7nPi 6j9g== X-Forwarded-Encrypted: i=1; AKwUvBxYlS4R8zhI11sUCP0SWEkQvmL4qlfo87ncNGj47wB6fq5negmyXgHMv15rA+eKAMhm+ys16IQyfCaqwHw=@vger.kernel.org X-Gm-Message-State: AFq9FYLTKTk++2Ctb61AlMS2zU5E41/EUDW9AdjqrnZ0fxXSrgRxmLez H/+JI2TScya7d5aSMFot0U9ZJ2UxmSZrgi+9mSKoAA0oaViEIECJeTXTXFWbXVKrjvSolNB5Es1 lVL0Bjwxafu6MM1/SxA== X-Received: from edve18.prod.google.com ([2002:a05:6402:1492:b0:6b3:c422:923c]) (user=tarunsahu job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:5191:b0:6b1:b97b:744 with SMTP id 4fb4d7f45d1cf-6b442ff3810mr590380a12.32.1792792312470; Fri, 23 Oct 2026 14:51:52 -0700 (PDT) Date: Fri, 23 Oct 2026 21:51:51 +0000 In-Reply-To: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 References: <20261021152527.375070-1-tarunsahu@google.com> <20261021152527.375070-2-tarunsahu@google.com> <9huzik2u6hs5.fsf@tarunix.c.googlers.com> <9huzld7q4zjz.fsf@tarunix.c.googlers.com> Message-ID: <9huz33twf5l4.fsf@tarunix.c.googlers.com> Subject: Re: [RFC PATCH v2 1/4] liveupdate: Rename handler compatible to name From: tarunsahu@google.com To: Mike Rapoport Cc: Pasha Tatashin , Andrew Morton , joro@8bytes.org, Pratyush Yadav , maz@kernel.org, arnd@arndb.de, David Matlack , 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 , Bjorn Helgaas , 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike Rapoport writes: > On Wed, Oct 21, 2026 at 07:35:28PM +0000, tarunsahu@google.com wrote: >> Pasha Tatashin writes: >> > On Wed, Oct 21, 2026 at 2:16=E2=80=AFPM wrote: >> >> Pasha Tatashin writes: >> >> >> >> > On Wed, Oct 21, 2026 at 11:25=E2=80=AFAM Tarun Sahu 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 file= s. >> >> >> - * @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 lik= e >> >> handler with compatible string this and handler with compatible strin= g >> >> that. >> > >> > I still feel like compatability makes more sense to me. Take an exampl= e: >> > >> > We have two file handlers for memfd (i.e., FH_OLD and FH_NEW): one has >> > compatibility =3D "memfd", and the other has compatibility =3D >> > "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. >>=20 >> I will open this for vote. > > I'd rather won't ;-) > > "compatible" does not contradict more fine grained bitfields, and still h= as meaning. > Just like in FDT world from where we inherited it, it means "these ops ar= e > somewhat compatible with that serialized format, will check the details a= nd > will know for sure". > > And IMO we should keep it. > =20 > 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 threa= d). ~Tarun > > --=20 > Sincerely yours, > Mike.