[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] cmdline_parse: Also pass bool_assert to OPT_CUSTOM so that parse_bool can be used correctly.
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |