From: Conor Dooley <conor@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-parisc@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
nathan@kernel.org, Conor Dooley <conor.dooley@microchip.com>,
joe@perches.com, linux-riscv@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required
Date: Mon, 4 Dec 2023 16:14:45 +0000 [thread overview]
Message-ID: <20231204-liftoff-enclosure-d3e3daf0ab6e@spud> (raw)
In-Reply-To: <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
[-- Attachment #1: Type: text/plain, Size: 4599 bytes --]
On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> On 12/01/23 at 10:38am, Conor Dooley wrote:
> > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> >
> > $subject has a typo in the arch bit :)
>
> Indeed, will fix if need report. Thanks for careful checking.
>
> >
> > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > loading related codes.
> >
> > Commit messages should be understandable in isolation, but this only
> > explains (part of) what is obvious in the diff. Why is this change
> > being made?
>
> The purpose has been detailedly described in cover letter and patch 1
> log. Andrew has picked these patches into his tree and grabbed the cover
> letter log into the relevant commit for people's later checking. All
> these seven patches will be present in mainline together. This is common
> way when posting patch series? Please let me know if I misunderstand
> anything.
Each patch having a commit message that explains why a change is being
made is the expectation. It is especially useful to explain the why
here, since it is not just a mechanical conversion of pr_debug()s as the
commit message suggests.
> >
> > >
> > > And also remove kexec_image_info() because the content has been printed
> > > out in generic code.
> > >
> > > Signed-off-by: Baoquan He <bhe@redhat.com>
> > > ---
> > > arch/riscv/kernel/elf_kexec.c | 11 ++++++-----
> > > arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> > > 2 files changed, 6 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > > index e60fbd8660c4..5bd1ec3341fe 100644
> > > --- a/arch/riscv/kernel/elf_kexec.c
> > > +++ b/arch/riscv/kernel/elf_kexec.c
> > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > if (ret)
> > > goto out;
> > > kernel_start = image->start;
> > > - pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> > >
> > > /* Add the kernel binary to the image */
> > > ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > image->elf_load_addr = kbuf.mem;
> > > image->elf_headers_sz = headers_sz;
> > >
> > > - pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > - image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > + kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > + image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > >
> > > /* Setup cmdline for kdump kernel case */
> > > modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > pr_err("Error loading purgatory ret=%d\n", ret);
> > > goto out;
> > > }
> > > + kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > > +
> > > ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> > > &kernel_start,
> > > sizeof(kernel_start), 0);
> > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > if (ret)
> > > goto out;
> > > initrd_pbase = kbuf.mem;
> >
> > > - pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > + kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> >
> > This is not a pr_debug().
> >
> > > }
> > >
> > > /* Add the DTB to the image */
> > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > }
> > > /* Cache the fdt buffer address for memory cleanup */
> > > image->arch.fdt = fdt;
> >
> > > - pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > + kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> >
> > Neither is this. Why are they being moved from pr_notice()?
>
> You are right.
>
> While always printing out the loaded location of purgatory and
> device tree doesn't make sense. It will be confusing when users
> see these even when they do normal kexec/kdump loading. It should be
> changed to pr_debug().
>
> Which way do you suggest?
> 1) change it back to pr_debug(), fix it in another patch;
> 2) keep it as is in the patch;
Personally I think it is fine to change them all in one patch, but the
rationale for converting pr_notice() to your new debug infrastructure
needs to be in the commit message.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-12-04 16:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 2:39 [PATCH v3 0/7] kexec_file: print out debugging message if required Baoquan He
2023-11-30 2:39 ` [PATCH v3 1/7] kexec_file: add kexec_file flag to control debug printing Baoquan He
2023-11-30 2:39 ` [PATCH v3 2/7] kexec_file: print out debugging message if required Baoquan He
2023-11-30 2:52 ` Joe Perches
2023-12-04 8:43 ` Baoquan He
2023-11-30 2:39 ` [PATCH v3 3/7] kexec_file, x86: " Baoquan He
2023-11-30 2:39 ` [PATCH v3 4/7] kexec_file, arm64: " Baoquan He
2023-11-30 2:39 ` [PATCH v3 5/7] kexec_file, ricv: " Baoquan He
2023-12-01 10:38 ` Conor Dooley
2023-12-04 15:38 ` Baoquan He
2023-12-04 16:14 ` Conor Dooley [this message]
2023-12-06 15:37 ` Baoquan He
2023-12-06 16:54 ` Conor Dooley
2023-12-06 23:22 ` Baoquan He
2023-12-13 3:23 ` Baoquan He
2023-11-30 2:39 ` [PATCH v3 6/7] kexec_file, power: " Baoquan He
2023-11-30 2:39 ` [PATCH v3 7/7] kexec_file, parisc: " 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=20231204-liftoff-enclosure-d3e3daf0ab6e@spud \
--to=conor@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=conor.dooley@microchip.com \
--cc=joe@perches.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nathan@kernel.org \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).