Re: [PATCH v2] init: Print out unknown kernel parameters

[Andrew Halaney <ahalaney@redhat.com>]

On Wed, May 12, 2021 at 04:00:21PM -0700, Randy Dunlap wrote:
> On 5/11/21 2:10 PM, Andrew Halaney wrote:
> > It is easy to foobar setting a kernel parameter on the command line
> > without realizing it, there's not much output that you can use to
> > assess what the kernel did with that parameter by default.
> > 
> > Make it a little more explicit which parameters on the command line
> > _looked_ like a valid parameter for the kernel, but did not match
> > anything and ultimately got tossed to init. This is very similar to the
> > unknown parameter message received when loading a module.
> > 
> > This assumes the parameters are processed in a normal fashion, some
> > parameters (dyndbg= for example) don't register their
> > parameter with the rest of the kernel's parameters, and therefore
> > always show up in this list (and are also given to init - like the
> > rest of this list).
> > 
> > Another example is BOOT_IMAGE= is highlighted as an offender, which it
> > technically is, but is passed by LILO and GRUB so most systems will see
> > that complaint.
> > 
> > An example output where "foobared" and "unrecognized" are intentionally
> > invalid parameters:
> > 
> >   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
> >   Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo
> 
> Hi Andrew,
> What order is the list of unknown command line parameters listed in?

Hi Randy,

That's a good question considering that they are out of order in my
example output compared to the command line. The order is parameters
without an "=val", then those with an "=val", and within those groups
they should be ordered as they are on the command line.

This is because I'm using the processing work done by
unknown_bootoption(), which stores them in two separate lists to pass to
init later (for arguments and environment). I am "stealing" from those
here:

	for (p = &argv_init[1]; *p; p++)
		end += sprintf(end, " %s", *p);
	for (p = &envp_init[2]; *p; p++)
		end += sprintf(end, " %s", *p);

hence the differing output order from the command line. I didn't
see much value in trying to duplicate that processing logic to get them in
a single list in the order of the command line itself. I debated looking
at the command line and searching each of the offending lists for that
entry to get them in the order of the command line but decided to keep
it simple here since it was achieving what I wanted.

Thanks,
Andrew