qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 07/13] Monitor: handle optional '-' arg as a boo


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 07/13] Monitor: handle optional '-' arg as a bool
Date: Wed, 23 Jun 2010 17:05:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Luiz Capitulino <address@hidden> writes:

> Historically, user monitor arguments beginning with '-' (eg. '-f')
> were passed as integers down to handlers.
>
> I've maintained this behavior in the new monitor because we didn't
> have a boolean type at the very beginning of QMP. Today we have it
> and this behavior is causing trouble to QMP's argument checker.
>
> This commit fixes the problem by doing the following changes:
>
> 1. User Monitor
>
>    Before: the optional arg was represented as a QInt, we'd pass 1
>            down to handlers if the user specified the argument or
>            0 otherwise
>
>    This commit: the optional arg is represented as a QBool, we pass
>                 true down to handlers if the user specified the
>                 argument, otherwise _nothing_ is passed
>
> 2. QMP
>
>    Before: the client was required to pass the arg as QBool, but we'd
>            convert it to QInt internally. If the argument wasn't passed,
>            we'd pass 0 down
>
>    This commit: still require a QBool, but doesn't do any conversion and
>                 doesn't pass any default value
>
> 3. Convert existing handlers (do_eject()/do_migrate()) to the new way
>
>    Before: Both handlers would expect a QInt value, either 0 or 1
>
>    This commit: Change the handlers to accept a QBool, they handle the
>                 following cases:
>
>                    A) true is passed: the option is enabled
>                    B) false is passed: the option is disabled
>                    C) nothing is passed: option not specified, use
>                                          default behavior

Because the user monitor can't pass false, the only sensible default
behavior is "disabled".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]