All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: akpm@linux-foundation.org, Qiang Ma <maqianga@uniontech.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	shivang upadhyay <shivangu@linux.ibm.com>
Subject: Re: [PATCH v3 0/3] kexec: print out debugging message if required for kexec_load
Date: Sun, 30 Nov 2025 10:56:33 +0800	[thread overview]
Message-ID: <aSuyYXnVqPp0HGwt@MiWiFi-R3L-srv> (raw)
In-Reply-To: <77ce0329-1f82-49be-b18a-73c9e5c3e85e@linux.ibm.com>

On 11/28/25 at 03:11pm, Sourabh Jain wrote:
> Hello Baoquan,
> 
> On 27/11/25 21:00, Baoquan He wrote:
> > On 11/27/25 at 05:31pm, Sourabh Jain wrote:
> > > Hello All,
> > > 
> > > Do we have plan to support KEXEC_DEBUG flag?
> > > 
> > > Because upstream kexec-tools already added support for KEXEC_DEBUG flag
> > > and that breaks the kexec_load with -d option.
> > > 
> > > - kexec: add kexec flag to support debug printing
> > >    https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=71d6fd99af7e
> > I think we should revert that kexec-tools commit.
> 
> Yeah, userspace changes shouldn't go in until the kernel patches are
> finalized. It seems that there are disagreements regarding the approach
> and usefulness of this patch series, so reverting the kexec-tools patch
> might be the right thing to avoid breaking anything for now.

The patch 1 is issue fixing, that is a good one. While patch 2, 3 are
trying to add debugging printing for kexec_load interface which I think
is not needed. I added debugging printing for kexec_file_load because I
has been using 'kexec -d' to debug for kexec_load while kexec_file_load
didn't have. So I mimicked kexec_load's debugging printing to add one
for kexec_file_load. Now patch 2,3's adding doesn't make sense as he
said he is doing for future need.

> 
> I have one question: should the kernel advertise KEXEC_DEBUG so that
> backward compatibility can be maintained between the kernel and
> kexec-tools? Or is that too much for a debugging flag? How was backward
> compatibility handled when we added the KEXEC_FILE_DEBUG flag?

When I added KEXEC_FILE_DEBUG, I didn't consider backward compatibility.
That is making the then latest kernel match the then latest kexec-tools.

> 
> > This whole patchset is
> > non-sense. Because of my carelessness, that userspace patch was merged.
> > 
> > Hi Sourabh,
> > 
> > Could you go through this patchset and help check if they are really
> > needed? I can't find anything to convince myself. Thanks.
> 
> Sure I will review this patch series.

Thanks. Please check patch 2,3 to see if we really need the debugging
printing for kexec_load, or its adding really brings benefit even if
it's a little bit compared with the mess it brings; and if my objecting
is too subjective.

Thanks
Baoquan



  reply	other threads:[~2025-11-30  2:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-26  8:44 [PATCH v3 0/3] kexec: print out debugging message if required for kexec_load Qiang Ma
2025-11-26  8:44 ` [PATCH v3 1/3] kexec: Fix uninitialized struct kimage *image pointer Qiang Ma
2025-11-26  8:44 ` [PATCH v3 2/3] kexec: add kexec flag to control debug printing Qiang Ma
2025-11-26  8:44 ` [PATCH v3 3/3] kexec: print out debugging message if required for kexec_load Qiang Ma
2025-11-27  1:47 ` [PATCH v3 0/3] " Baoquan He
2025-11-27  2:04   ` Qiang Ma
2025-11-27  2:36     ` Baoquan He
2025-11-27  3:00       ` Qiang Ma
2025-11-27  3:55         ` Baoquan He
2025-11-27  6:59           ` Qiang Ma
2025-11-27 12:01 ` Sourabh Jain
2025-11-27 15:30   ` Baoquan He
2025-11-28  9:41     ` Sourabh Jain
2025-11-30  2:56       ` Baoquan He [this message]
2025-12-04 12:18 ` Sourabh Jain
2025-12-05  9:20   ` Qiang Ma
2025-12-09  0:45   ` Baoquan He

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=aSuyYXnVqPp0HGwt@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maqianga@uniontech.com \
    --cc=shivangu@linux.ibm.com \
    --cc=sourabhjain@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.