From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: NMI: watchdog timeout command line parameter Date: Thu, 8 Mar 2012 10:22:13 +0000 Message-ID: <1331202133.32288.43.camel@elijah> References: <4F57A586.2000701@citrix.com> <4F5892AD020000780007714B@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F5892AD020000780007714B@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , Andrew Cooper , Keir Fraser , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 2012-03-08 at 10:06 +0000, Jan Beulich wrote: > >>> On 07.03.12 at 19:14, Andrew Cooper wrote: > > Here is a patch which allows a command line parameter to set the > > watchdog timeout. > > Wouldn't it make sense to simply modify the watchdog= semantics > slightly: When given a numeric value, it specifies the timeout (and zero > disables as before), while when given any value parse_bool() accepts > the timeout remains at the default and the watchdog just gets turned > on. I had thought of this too, but I don't think it actually simplifies it. It makes the parsing code more complicated, and it makes the interface actually more complicated and less predictable, for pretty much no good reason. It's not like adding extra command-line options is really onerous, either in terms of users or in terms of our code. I think it's much more important to have consistency and predictability; the new interpretation "watchdog=1" is exactly the kind of thing we need to avoid. -George > The only ambiguity with the current possible values would be > watchdog=1, and I think having the meaning of this changed is > acceptable. > > Jan >