[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 07/28/14 12:23, Andrew Cooper wrote:
On 28/07/14 17:18, Don Slutz wrote:

On 07/28/14 12:08, Andrew Cooper wrote:
On 28/07/14 16:59, Don Slutz wrote:
Based on:

commit 2fcb51bc7a4fcb7534265d7bb155c6ddf03952b8
Author:kfraser@xxxxxxxxxxxxxxxxxxxxx  <kfraser@xxxxxxxxxxxxxxxxxxxxx>
Date:   Mon Jul 9 14:29:53 2007 +0100

     Also allow boolean cmdline params to be inverted in two other ways.

     Now, a standard boolean (e.g., watchdog) can be inverted in three
      1. no-watchdog
      2. watchdog=no
      3. watchdog=off

     Stacked inversions cancel each other: no-watchdog=no turns on the

bool_assert is needed to do stacked inversions with parse_bool.

Signed-off-by: Don Slutz<dslutz@xxxxxxxxxxx>

Why do we need to care about stacked inversions?

From xen-command-line.markdown:

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

Ah, I see that:

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

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

    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxx>
    Committed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

was when this changed.

The command line:

no-console_timestamps dom0_mem=3G loglvl=all guest_loglvl=all com1=9600,8n1 console=com1 crashkernel=256M@256M no-console_timestamps=no

in 4.4 and before ends up with date style console_timestamps. In xen 4.5 you get no console_timestamps.

The simpler case of no-console_timestamps no longer works also.

   -Don Slutz

Ok, so my "compat for older console_timestamp boolparam" needs improving a bit.

Yes, that is what patch #2 does.

However, "no-console_timestamps=no" is undefined, and we make no guarentees as to what happens if you give repeated (different) command line options to Xen. Both of these are user/admin error and should not be worked around in Xen code.


Ok, I was not aware of this change in "defined" behavior. I will re-work this
to include Jan's 'pass "no" if "no-" removed.'

   -Don Slutz

Xen-devel mailing list



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