From: Pratyush Yadav <pratyush@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Alexander Graf <graf@amazon.com>,
Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
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
Date: Wed, 14 Jan 2026 19:19:11 +0000 [thread overview]
Message-ID: <2vxzy0m0gfyo.fsf@kernel.org> (raw)
In-Reply-To: <20260108-kho-v3-1-b1d6b7a89342@debian.org> (Breno Leitao's message of "Thu, 08 Jan 2026 08:40:58 -0800")
Hi Breno,
On Thu, Jan 08 2026, Breno Leitao wrote:
> Store and display the kernel version from the previous kexec boot.
>
> The current kernel's release string is saved to the "previous-release"
> property in the KHO FDT before kexec. On the next boot, if this property
> exists, the previous kernel version is retrieved and printed during
> early boot.
>
> This helps diagnose bugs that only manifest when kexecing from specific
> kernel versions, making it easier to correlate crashes with the kernel
> that initiated the kexec.
The KHO FDT is ABI. So you should be bumping the version number when you
make changes to it.
But honestly, adding this "optional" stuff to the core KHO ABI makes me
uneasy. I say optional since it is not needed for the main functionality
of KHO. Making this a part of the ABI increases the surface area we
have. The more things we stuff in the ABI, the more inflexible it gets
over time.
Any changes to the KHO ABI means all consumers also need a version bump.
This includes LUO and all its users for example. So I would really like
to avoid adding optional things in core KHO FDT.
The easy fix is to add a separate subtree for the optional metadata. You
would still need to create an ABI for the data format, but being
independent of core KHO, it will make it more flexible and easier to
change in the future. You can keep the code in kexec_handover.c.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
[...]
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-01-14 19:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 16:40 [PATCH v3 0/2] kho: history: track previous kernel version and kexec boot count Breno Leitao
2026-01-08 16:40 ` [PATCH v3 1/2] kho: history: track previous kernel version Breno Leitao
2026-01-14 19:19 ` Pratyush Yadav [this message]
2026-01-08 16:40 ` [PATCH v3 2/2] kho: history: track kexec boot counter Breno Leitao
2026-01-09 1:45 ` [PATCH v3 0/2] kho: history: track previous kernel version and kexec boot count SeongJae Park
2026-01-09 11:00 ` Breno Leitao
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=2vxzy0m0gfyo.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=clm@fb.com \
--cc=graf@amazon.com \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--cc=rppt@kernel.org \
--cc=usamaarif642@gmail.com \
/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