From mboxrd@z Thu Jan  1 00:00:00 1970
From: Don Slutz <dslutz@verizon.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 16:30:19 -0400
Message-ID: <53D6B2DB.4080604@terremark.com>
References: <1406563175-23761-1-git-send-email-dslutz@verizon.com>
	<1406563175-23761-2-git-send-email-dslutz@verizon.com>
	<53D691420200007800026CAD@mail.emea.novell.com>
	<53D68488.3060204@terremark.com> <53D6A23A.5020702@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <53D6A23A.5020702@gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Keir Fraser <keir.xen@gmail.com>, 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>
List-Id: xen-devel@lists.xenproject.org

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):


>>> On 28.07.14 at 18:18, <dslutz@verizon.com> wrote:
> The simpler case of no-console_timestamps no longer works also.

Which I believe would be made work by faking up a "no" string when
calling the custom handler, without touching dozens of files.

Jan




I was reading this as "no-lapic" is the same as "lapic=no".  I can reject
"no-lapic=no" (or any other "=<value>")for custom parameters (since

commit 6328e728f6d6589a10d7e9f97a47f566f63743c2
Author: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date:   Mon Sep 3 11:22:00 2012 +0100

     docs/command line: Clarify the behavior with invalid input.

) says that:


Explicitly specifying any value other than those listed above is
undefined, as is stacking a `no-` prefix with an explicit value.


    -Don Slutz

> Adding a bool parameter to every custom parameter parser is not really 
> going to fly.
>
>  -- Keir