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 804252DC33F for ; Wed, 14 Jan 2026 19:05:12 +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=1768417512; cv=none; b=m12Uz530rICRkge18uLlGLC4nPTiFG971rd795ksbP8p5oMoWhWtAlk24OxE116t8MdS31HR6oUzKDp6jwv5fZBJSJhcaSGR/DAxrDbTU/JpxyUrn+ZHMXk650g96hhd1jfIIB+BLXs6JGYKbyYNHqUhbU2vK2rVHziskqL7/3Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768417512; c=relaxed/simple; bh=2QKYOyEjrfuxHKVNPGX4pgerNIQSPvRZMBbE7X+COHs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=HFzCg9Ly5jfi6e9iO/2hh7ylmUlkAOUUYZ30czyF/kXKmtQTgb12g75OlyHCdgDZU8vxU1Ch0pBRHNdVOSkgZSEbpP6APzAcfi4vqn0yo/o/dqEl99ulImMjJXQPsVumcG57Ly7KhIjVbo/VG5wPSLSgxeW0LjlKoapnf146EMw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TBE16hKH; 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="TBE16hKH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10075C4CEF7; Wed, 14 Jan 2026 19:05:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768417512; bh=2QKYOyEjrfuxHKVNPGX4pgerNIQSPvRZMBbE7X+COHs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TBE16hKH5B1htBPywslXb3uE1G9s3+1zukbdGdlVTRKU9+GHpwxCGNVyD1rJDG1sM ypztzWs0yTDPqUuo7+Okx21fYvpOZtelOEspY4N6lXkNszYpELSMVN38Q1hHI8MSlq FWHgj/wokP9nwQNMeJQ63AH6rS9qTMdQjX6jVx0AybrqYwcB7BIuXADDiJ7tPTDnuW LD2sI+eUuTnrqfONFyvw7KdIaO48b21ooICSQyR5GtdjgqDLPDB7z9CMO4L4pV9iVS ob5xMRHaDy6gwcsXgZYz/BGOHmAhKuXjDI6lXx7WxrfA2J8nUuvjDRp69QFrjmNZ4g Otpd4WLe8rG2A== From: Pratyush Yadav To: Breno Leitao Cc: Pratyush Yadav , Alexander Graf , Mike Rapoport , 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 v2 2/2] kexec: history: track kexec boot counter In-Reply-To: (Breno Leitao's message of "Tue, 6 Jan 2026 03:04:28 -0800") References: <20260102-kho-v2-0-1747b1a3a1d6@debian.org> <20260102-kho-v2-2-1747b1a3a1d6@debian.org> <86o6nb7oi1.fsf@kernel.org> Date: Wed, 14 Jan 2026 19:05:08 +0000 Message-ID: <2vxza4yghv6j.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Jan 06 2026, Breno Leitao wrote: > On Fri, Jan 02, 2026 at 09:23:18PM +0100, Pratyush Yadav wrote: >> On Fri, Jan 02 2026, Breno Leitao wrote: >> >> > Track and display the number of kexec boots since the last cold reboot >> >> Nit: this does not track kexec boots, it tracks KHO boots. None of this >> can work on normal kexec boots. Can you please update the wording to >> make that clear? >> >> > when CONFIG_KEXEC_HISTORY is enabled. >> > >> > This extends the previous kernel release tracking feature by adding >> > a counter that increments with each kexec boot. The counter provides >> > visibility into the kexec chain depth, which is useful for understanding >> > boot history in production environments. >> > >> > Add a new property, "kexec-count" in KHO FDT alongside the existing >> > "previous-release" property. The counter is: >> > >> > - Initialized to 0 when kho_in is instantiated. >> > - Incremented by 1 on each subsequent kexec. >> > - Printed alongside the previous kernel release version. >> > >> > The counter is stored as a 32-bit unsigned integer in FDT format and is >> > only active when CONFIG_KEXEC_HISTORY is enabled. >> >> We have such a counter for LUO as well from the properly >> "liveupdate-number". If you're using LUO, why can't you use that counter >> directly? >> >> If you're not using LUO, I'm curious, what's your use case? Right now >> KHO only supports reserve-mem outside of LUO. Is that what you plan to >> use? >> >> Also, do we want to keep both counters independently? Or do we have one >> and drop the other? Pasha, what do you think? > > In fact, I do not have plan to use LUO right now. My goal is to pass the > kexec release from kernel to another, and for that I am using KHO to > pass this information. Oh, cool. Nice to see other use cases for KHO. > > That said, I am planning to use KHO as the infrastructure to pass the > kernel version from one kernel to another. > > Given that I don't think this "feature" should depend on LUO, maybe the > counters should be independent (?!) If you aren't using LUO then you certainly can't use its counter. But LUo users are all KHO users. So perhaps we can get away with removing the LUO one and moving it to KHO? -- Regards, Pratyush Yadav