[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()



>>> On 25.08.17 at 10:31, <jgross@xxxxxxxx> wrote:
> On 24/08/17 17:43, Andrew Cooper wrote:
>> I had planned to modify parse_bool() to be
>> 
>> int parse_bool(const char *field, const char *s)
>> {
>>     ...
>> }
>> 
>> which cases care of considering the "no-" prefix, optionally skips the
>> field name if it matches exactly, and then performs the current logic on
>> the remainder of the string.  This way, boolean options should work
>> consistently wherever they are.
>> 
>> It also means that a lot of custom_params() need simplifying to always
>> pass intended boolean options to parse_bool().
> 
> I believe they do so in most cases.
> 
>> Could we see about merging this work together, rather than having two
>> series going and modifying how the parsing works?
> 
> Hmm, I'm not sure it is worth the effort. Doing a quick search I found
> only the iommu case where this would be relevant. All other cases are
> handled correctly by _cmdline_parse(): a custom parameter prefixed with
> "no-" is accepted only without a value specification.
> 
> I'd rather add one further patch to my series to correct the iommu case
> and another one to fix _cmdline_parse() for the other cases where the
> "no-" prefix is accepted for non-boolean parameters.

Note how Andrew did say "sub-option": Just grep for "no-" (including
the quotes) and you'll find a few more examples.

I'm not, however, convinced that this really should be done in this
series, as the goal is quite a different one. Yes, this would mean
touching parse_bool() callers a second time, but that's the way
things work.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.