[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77ce0329-1f82-49be-b18a-73c9e5c3e85e@linux.ibm.com>
Date: Fri, 28 Nov 2025 15:11:54 +0530
From: Sourabh Jain <sourabhjain@...ux.ibm.com>
To: Baoquan He <bhe@...hat.com>, akpm@...ux-foundation.org
Cc: Qiang Ma <maqianga@...ontech.com>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org,
shivang upadhyay <shivangu@...ux.ibm.com>
Subject: Re: [PATCH v3 0/3] kexec: print out debugging message if required for
kexec_load
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.
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?
> 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,
Sourabh Jain
Powered by blists - more mailing lists