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@xxxxxxxxxx> > > > --- > > > 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:
signature.asc
Description: PGP signature