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

[Randy Dunlap <rdunlap@infradead.org>]

On 5/13/21 6:00 AM, Andrew Halaney wrote:
> 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 for explaining. That's what I was looking for.

-- 
~Randy