| Message ID | 20170814070849.20986-45-jgross@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 14.08.17 at 09:08, <jgross@suse.com> wrote: > With _cmdline_parse() now issuing error messages in case of illegal > parameters signalled by parsing functions specified in custom_param() > some messages issued by parse_low_crashinfo() and > parse_crashinfo_maxaddr() can be removed. But you realize this results in less information being conveyed (the defaults being fallen back to)? Jan
On 14/08/17 10:39, Jan Beulich wrote: >>>> On 14.08.17 at 09:08, <jgross@suse.com> wrote: >> With _cmdline_parse() now issuing error messages in case of illegal >> parameters signalled by parsing functions specified in custom_param() >> some messages issued by parse_low_crashinfo() and >> parse_crashinfo_maxaddr() can be removed. > > But you realize this results in less information being conveyed > (the defaults being fallen back to)? Yes. I guess it is a matter of taste which messages to keep. You will have noticed I kept some other messages especially for the crashkernel parameter which are not so obvious. In case you want me to keep other messages I'm fine to do so, of course. I could modify the messages to just print the used defaults if you like that better. Another possibility would be to always print the used parameters at the end of parse_crashkernel(). Juergen
>>> On 14.08.17 at 11:07, <jgross@suse.com> wrote: > On 14/08/17 10:39, Jan Beulich wrote: >>>>> On 14.08.17 at 09:08, <jgross@suse.com> wrote: >>> With _cmdline_parse() now issuing error messages in case of illegal >>> parameters signalled by parsing functions specified in custom_param() >>> some messages issued by parse_low_crashinfo() and >>> parse_crashinfo_maxaddr() can be removed. >> >> But you realize this results in less information being conveyed >> (the defaults being fallen back to)? > > Yes. I guess it is a matter of taste which messages to keep. You will > have noticed I kept some other messages especially for the crashkernel > parameter which are not so obvious. > > In case you want me to keep other messages I'm fine to do so, of course. > > I could modify the messages to just print the used defaults if you like > that better. > > Another possibility would be to always print the used parameters at the > end of parse_crashkernel(). Let's see what Andrew thinks. Jan
diff --git a/xen/common/kexec.c b/xen/common/kexec.c index d647a6c30e..d2fbf9eb80 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -213,7 +213,6 @@ static int __init parse_low_crashinfo(const char * str) low_crashinfo_mode = LOW_CRASHINFO_ALL; else { - printk("Unknown low_crashinfo parameter '%s'. Defaulting to min.\n", str); low_crashinfo_mode = LOW_CRASHINFO_MIN; return -EINVAL; } @@ -240,11 +239,7 @@ static int __init parse_crashinfo_maxaddr(const char * str) if ( (addr = parse_size_and_unit(str, &q)) ) crashinfo_maxaddr = addr; else - { - printk("Unable to parse crashinfo_maxaddr. Defaulting to %"PRIpaddr"\n", - crashinfo_maxaddr); return -EINVAL; - } return *q ? -EINVAL : 0; }
With _cmdline_parse() now issuing error messages in case of illegal parameters signalled by parsing functions specified in custom_param() some messages issued by parse_low_crashinfo() and parse_crashinfo_maxaddr() can be removed. Cc: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com> --- xen/common/kexec.c | 5 ----- 1 file changed, 5 deletions(-)