From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpwxR-0003vM-IG for qemu-devel@nongnu.org; Mon, 09 Dec 2013 04:16:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VpwxL-000072-JP for qemu-devel@nongnu.org; Mon, 09 Dec 2013 04:16:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpwxL-00006s-BM for qemu-devel@nongnu.org; Mon, 09 Dec 2013 04:16:47 -0500 From: Markus Armbruster References: <1386576358-10469-1-git-send-email-akong@redhat.com> <1386576358-10469-2-git-send-email-akong@redhat.com> Date: Mon, 09 Dec 2013 10:16:38 +0100 In-Reply-To: <1386576358-10469-2-git-send-email-akong@redhat.com> (Amos Kong's message of "Mon, 9 Dec 2013 16:05:57 +0800") Message-ID: <878uvufkp5.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v2 1/2] fix a typo of strict option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amos Kong Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws Amos Kong writes: > The type of "strict" should be bool. > > Signed-off-by: Amos Kong > --- > vl.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/vl.c b/vl.c > index b0399de..12fe1f7 100644 > --- a/vl.c > +++ b/vl.c > @@ -461,7 +461,7 @@ static QemuOptsList qemu_boot_opts = { > .type = QEMU_OPT_STRING, > }, { > .name = "strict", > - .type = QEMU_OPT_STRING, > + .type = QEMU_OPT_BOOL, > }, > { /*End of list */ } > }, No, this isn't just a typo fix, it's an interface change. It's not immediately obvious whether it's okay. -boot parameter 'strict' appeared in commit c8a6ae8. It was declared QEMU_OPT_STRING, but the code using the value rejected anything but 'on' and 'off'. This shipped in 1.5.0. Commit 6ef4716 accidentally dropped the code using the value of 'strict'. Since then, any parameter value is accepted and silently ignored. Shipped in 1.6.0. Your change restores the "reject anything but 'on' and 'off'" part (the "use the value" part gets restored in the next patch). Okay, because the values erroneously accepted in the meantime didn't do anything.