From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88FEB44CF48 for ; Tue, 20 Jan 2026 18:58:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768935492; cv=none; b=vFG+dfMueR2pLsdJnrs6JHSJGIs1FKaGLpdvDvN1ojUht8TJyPTAHeM0xnBeYk10JikpGYdh1kMiCTS9hm2nbBMyGS5QfT+3n6Aojjf78cmbUhQBEvN4fbkZL1WuKUCTvbq4RPBk+OqiZe5qVk5XuoX27lcbqORVddNlCQCxqmI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768935492; c=relaxed/simple; bh=I5q0oGB+BoA/gz8qsotA61iskY7SDlYKob9LdnVdGNY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mOPHllsIw/NQS/5MmbQ0ifWueNBM19udEEJgqyyrIbblyTz4/snTima38PihOt/AyBkshvz/6J3FH8sGKwj0UfWKdIjwTaRMshKKJO/L+/99gaSSpdIR15QqnMwGEpQdc4/0guUwZ3J/Z/JMHyfMCSSBLoBlIMve0WV58i/HjQ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GhB7IVkw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GhB7IVkw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EEA8C16AAE; Tue, 20 Jan 2026 18:58:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768935490; bh=I5q0oGB+BoA/gz8qsotA61iskY7SDlYKob9LdnVdGNY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GhB7IVkwG/XveGj1F09VZwJYfZ6BTg7yXMg4IEJIePaigtf7knr23e4MQvTMxS+XR 3XGbUKDlpl5+VcPlQFcjc3V9gDkHfwLhvQtn1622KVxhrL30oJc5/p1DDSVoy5b+oK gBhlEsuMf2+/UQWGOlx0kq6hZGbVeB28j90YZPDymuuRHHHrT0mJOWLA4U3nnby16v xCMZ/fk+eOp/cSZbaK58BPKykl50BWitcslIvDcc3KdijKzNQ8tUR6m4ERC7oTDGHh 8D5Dnc+dFsby36GI2D0phtpjip1EDcbHqJ8Lu/KtkMuKJMuTGQxieNcRvQdi2kptia B2purnqkBT7Ig== Date: Tue, 20 Jan 2026 20:58:02 +0200 From: Mike Rapoport To: Pratyush Yadav Cc: Breno Leitao , Alexander Graf , Pasha Tatashin , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, usamaarif642@gmail.com, rmikey@meta.com, clm@fb.com, riel@surriel.com, kernel-team@meta.com Subject: Re: [PATCH v3 1/2] kho: history: track previous kernel version Message-ID: References: <20260108-kho-v3-0-b1d6b7a89342@debian.org> <20260108-kho-v3-1-b1d6b7a89342@debian.org> <2vxzy0m0gfyo.fsf@kernel.org> <2vxzms28e1ib.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2vxzms28e1ib.fsf@kernel.org> Hi, On Tue, Jan 20, 2026 at 03:40:12PM +0000, Pratyush Yadav wrote: > On Fri, Jan 16 2026, Breno Leitao wrote: > > > > On cold boot, kexec-count starts at 0 and increments with each kexec. > > The count helps identify issues that only manifest after multiple > > consecutive kexec reboots. > > Very well written changelog! @Breno, the submission would be perfect if you'd start a new thread rather than reply to v1 ;-) > > +/* > > + * The "history" subtree stores optional metadata about the kexec chain. > > + * It is registered as a separate FDT via kho_add_subtree(), keeping it > > + * independent from the core KHO ABI. This allows the history format to > > + * evolve without affecting other KHO consumers. > > + * > > + * The history FDT structure: > > I don't have a strong preference here, but you don't _have_ to use FDT. > For example, with memfd, we moved from FDT to plain C structs during the > evolution of the patchset. Main reason is that FDT programming is a bit > annoying. C structs make many things much easier. For example, you can > always assume a certain property always exists and is of a given size, > and you don't have to validate every single property you read. > > Anyway, I don't mind either way. Yeah, I agree that a plain C structure with an array of chars and u64 will make things simpler. > > + * > > + * / { > > + * compatible = "kho-history-v1"; > > + * previous-release = "6.x.y-..."; > > + * kexec-count = ; > > + * }; > > + */ > > +#define KHO_HISTORY_NODE_NAME "history" > > Do we want to call it history? Perhaps "kexec-metadata" instead? So we > could use it for other misc information if needed later. > > Mike/Pasha, any thoughts? I like kexec-metadata. -- Sincerely yours, Mike.