From: Keir Fraser <keir.xen@gmail.com>
To: Don Slutz <dslutz@verizon.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
Jan Beulich <JBeulich@suse.com>,
Liu Jinsong <jinsong.liu@alibaba-inc.com>,
Christoph Egger <chegger@amazon.de>,
Ian Jackson <ian.jackson@eu.citrix.com>,
xen-devel@lists.xen.org,
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 1/3] cmdline_parse: Also pass bool_assert to OPT_CUSTOM so that parse_bool can be used correctly.
Date: Mon, 28 Jul 2014 20:19:22 +0100 [thread overview]
Message-ID: <53D6A23A.5020702@gmail.com> (raw)
In-Reply-To: <53D68488.3060204@terremark.com>
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.
Adding a bool parameter to every custom parameter parser is not really
going to fly.
-- Keir
next prev parent reply other threads:[~2014-07-28 19:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 15:59 [PATCH 0/3] parse_bool fixes Don Slutz
2014-07-28 15:59 ` [PATCH 1/3] cmdline_parse: Also pass bool_assert to OPT_CUSTOM so that parse_bool can be used correctly Don Slutz
2014-07-28 16:06 ` Jan Beulich
2014-07-28 17:12 ` Don Slutz
2014-07-28 19:19 ` Keir Fraser [this message]
2014-07-28 20:30 ` Don Slutz
2014-07-29 6:35 ` Jan Beulich
2014-07-29 20:05 ` Don Slutz
2014-07-28 16:08 ` Andrew Cooper
2014-07-28 16:18 ` Don Slutz
2014-07-28 16:23 ` Andrew Cooper
2014-07-28 19:07 ` Don Slutz
2014-07-28 16:39 ` Jan Beulich
2014-07-28 15:59 ` [PATCH 2/3] xen/console: Better handing of console_timestamps as a boolean_param Don Slutz
2014-07-28 15:59 ` [PATCH 3/3] Adjust parse_vpmu_param use of parse_bool Don Slutz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D6A23A.5020702@gmail.com \
--to=keir.xen@gmail.com \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=JBeulich@suse.com \
--cc=chegger@amazon.de \
--cc=dslutz@verizon.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jinsong.liu@alibaba-inc.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@citrix.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.