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. 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 (?!) Thanks --breno
