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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.07.14 at 22:30, <dslutz@xxxxxxxxxxx> wrote:
> 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):

I'd say we should allow what is sensible, and reject nonsense. E.g.
"no-" on any option that has a value (following a = separator) makes
no sense. But custom options allowing other than boolean values
as their value can, when no value (and no = separator) was given,
meaningfully be prefixed by "no-", which could be resolved by the
faked up "=no" value I was suggesting in my earlier reply (at once
dealing with "no-" prefixes on custom options not allowing boolean
values: their parsing routine will simply reject the faked up "no").

Jan


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