Re: [PATCH] x86: kill arch/x86/kernel/mpparse.c debugging printk.

Cyrill Gorcunov
2008-08-11T19:02:16Z

[Ingo Molnar - Mon, Aug 11, 2008 at 08:49:03PM +0200]
|
| * Cyrill Gorcunov <gorcunov@gmail.com> wrote:
|
| > | early_param conversions - and i think highlighting that as
| > | separate commits might give someone ideas to improve the
| > | early_param() facility, if they see the fix patterns.
| >
| > Ingo - I think the problem with early_param is not NULL itself but
| > rather - what is the right way to deal with boot params? I mean we
| > could pass empty string (not NULL) in case of argument absence _but_
| > would it be the right way? If you remember when I sent first series
| > for early_param checking (and actually there are number of same issue
| > exists for example in s390 arch) - I was asking community what is the
| > best way - since I'm not that strong in interface engineering - i
| > prefer fix the bugs :)
|
| what would be the downside of passing in empty strings? I cannot see any
| serious one. The upside is that the conversion is more mechanic and
| safer as well.
|
| Maybe the return code inversion could be / should be fixed as well, that
| seems like an unnecessary change as well:
|
| - return 1;
| + return 0;
| }
| -__setup("apic=", apic_set_verbosity);
| +early_param("apic", apic_set_verbosity);
|
| Why do early-params have a different return convention from
| usual-params? It's just an unnecessary barrier against conversion to
| early params.
|
| Ingo
|

Actually - I don't know why is checking for 0. It's defined in
init/main.c:do_early_param -

if (p->setup_func(val) != 0)
printk(KERN_WARNING
"Malformed early option '%s'\n", param);

if we change it there - the lot of kernel code should be patched then.
I don't think it will be approved (even by being mechanical change) :)

To pass empty string - I think it's possible. I think I'll check it
tomorrow evening (have no time now). Or maybe someone else could
grep kernel tree to check if there only strcmp and conversion to
numeric values only (which shouldn't lead to any new bugs I hope :)

- Cyrill -