[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |