linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Fischetti <tony.fischetti@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	x86@kernel.org, hpa@zytor.com, dyoung@redhat.com,
	dave.hansen@linux.intel.com, linux@roeck-us.net,
	Kees Cook <keescook@chromium.org>,
	dan.j.williams@intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/setup: Add boot messages about cmdline builtins
Date: Fri, 24 Apr 2020 17:20:24 -0400	[thread overview]
Message-ID: <CAOMV6SXDe+h+H1jm4GOFt2qPC_fvkbTJ0ZQOdCZX0LD9+esKDQ@mail.gmail.com> (raw)
In-Reply-To: <20200422071100.GS4247@MiWiFi-R3L-srv>

I like the idea of printing the original one, printing the information
about the cmdline manipulation, and, then, printing the final one at the
end, too.

The only problem is I don't know what to label the first printk so that it
remains clear that it's not necessarily the _final_ one, yet.

In either case, they should probably be changed to `pr_info`s, right?


On Wed, Apr 22, 2020 at 3:11 AM Baoquan He <bhe@redhat.com> wrote:
>
> On 04/22/20 at 12:20am, Tony Fischetti wrote:
> > While the ability to override or append to the boot command line has
> > been added, the boot messages contain no information as to whether the
> > cmdline was manipulated by the build-time options. This patch, for x86,
> > adds boot messages specifying whether the cmdline was manipulated and
> > waits for the potential changes to take place before printing the final
> > boot command line.
> >
> > Signed-off-by: Tony Fischetti <tony.fischetti@gmail.com>
> > ---
> >  arch/x86/kernel/setup.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 4b3fa6cd3106..28d77f01fd0d 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -828,7 +828,6 @@ void __init setup_arch(char **cmdline_p)
> >        */
> >       __flush_tlb_all();
> >  #else
> > -     printk(KERN_INFO "Command line: %s\n", boot_command_line);
> >       boot_cpu_data.x86_phys_bits = MAX_PHYSMEM_BITS;
> >  #endif
> >
> > @@ -904,10 +903,12 @@ void __init setup_arch(char **cmdline_p)
> >
> >  #ifdef CONFIG_CMDLINE_BOOL
> >  #ifdef CONFIG_CMDLINE_OVERRIDE
> > +     pr_info("Overriding command line with builtin\n");
> >       strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> >  #else
> >       if (builtin_cmdline[0]) {
> >               /* append boot loader cmdline to builtin */
> > +             pr_info("Appending command line to builtin\n");
> >               strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> >               strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> >               strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> > @@ -916,6 +917,7 @@ void __init setup_arch(char **cmdline_p)
> >  #endif
> >
> >       strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
> > +     pr_info("Command line: %s\n", command_line);
>
> Yeah, adding info to tell there's action on overriding or apending
> command line looks good to me. Maybe keep the printing of the original
> command, we can get the final command line from '/proc/cmdline' after
> system boot, or just get it from the original cmdline + CONFIG_CMDLINE.
> Or print the original cmdline and the final cmdline both.
>
> Personal opinion.
>
> >       *cmdline_p = command_line;
> >
> >       /*
> > --
> > 2.20.1
> >
>


-- 
--
Tony Fischetti
tony.fischetti@gmail.com
(718) 431-4597

      reply	other threads:[~2020-04-24 21:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22  4:20 [PATCH] x86/setup: Add boot messages about cmdline builtins Tony Fischetti
2020-04-22  7:11 ` Baoquan He
2020-04-24 21:20   ` Tony Fischetti [this message]

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=CAOMV6SXDe+h+H1jm4GOFt2qPC_fvkbTJ0ZQOdCZX0LD9+esKDQ@mail.gmail.com \
    --to=tony.fischetti@gmail.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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).