Re: [Xen-devel] [PATCH 1/3] cmdline_parse: Also pass bool_assert to OPT_CUSTOM so that parse_bool can be used correctly.

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 07/28/14 12:06, Jan Beulich wrote:
> > > > On 28.07.14 at 17:59, <dslutz@xxxxxxxxxxx> wrote:
> > --- a/xen/arch/x86/apic.c
> > +++ b/xen/arch/x86/apic.c
> > @@ -809,20 +809,20 @@ int lapic_resume(void)
> >    * Original code written by Keir Fraser.
> >    */
> >   
> > -static void __init lapic_disable(char *str)
> > +static void __init lapic_disable(char *str, int bool_assert)
> >   {
> >       enable_local_apic = -1;
> >       setup_clear_cpu_cap(X86_FEATURE_APIC);
> >   }
> >   custom_param("nolapic", lapic_disable);
> >   
> > -static void __init lapic_enable(char *str)
> > +static void __init lapic_enable(char *str, int bool_assert)
> >   {
> >       enable_local_apic = 1;
> >   }
> >   custom_param("lapic", lapic_enable);
> >   
> > -static void __init apic_set_verbosity(char *str)
> > +static void __init apic_set_verbosity(char *str, int bool_assert)
> >   {
> >       if (strcmp("debug", str) == 0)
> >           apic_verbosity = APIC_DEBUG;
> This adding of a new parameter to all custom parameter parsers,
> with rarely any actually using it is a no-go as far as I'm concerned.
> That said, being of boolean type, this would need to be bool_t
> anyway.
I considered adding a new custom type, but when this way.  I would think 
that if a custom parameter parser is ignoring the "no-" (which they all do)
they should be reporting on it.


I.E. "no-lapic" currently means "lapic" and "no-nolapic" means "nolapic"
with out any message to that effect.

    -Don Slutz

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel