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 15:19, Keir Fraser wrote:
> Don Slutz wrote:
> > > 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.
> The better fix here would be to reject options such as "no-lapic" as 
> invalid. This could be done within cmdline_parse() by rejecting 
> matches on anything other than OPT_{BOOL,INVBOOL} options if optkey 
> has a "no-" prefix.
I read this as reject "no-" prefix for all custom parameters. Not
sure which way to go.  Jan says (on a different thread):


> > > On 28.07.14 at 18:18, <dslutz@xxxxxxxxxxx> wrote:
> The simpler case of no-console_timestamps no longer works also.
Which I believe would be made work by faking up a "no" string when
calling the custom handler, without touching dozens of files.

Jan




I was reading this as "no-lapic" is the same as "lapic=no".  I can reject
"no-lapic=no" (or any other "=<value>")for custom parameters (since

commit 6328e728f6d6589a10d7e9f97a47f566f63743c2
Author: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
Date:   Mon Sep 3 11:22:00 2012 +0100

    docs/command line: Clarify the behavior with invalid input.

) says that:


Explicitly specifying any value other than those listed above is
undefined, as is stacking a `no-` prefix with an explicit value.


   -Don Slutz

> Adding a bool parameter to every custom parameter parser is not really 
> going to fly.
>  -- Keir

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