From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mm5PR-0002jJ-0P
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:25 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mm5PL-0002Ys-I0
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:24 -0400
Received: from [199.232.76.173] (port=51474 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mm5PL-0002YW-Af
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:19 -0400
Received: from mx1.redhat.com ([209.132.183.28]:43229)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1Mm5PK-00056A-GQ
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:18 -0400
Received: from int-mx03.intmail.prod.int.phx2.redhat.com
	(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8BCdHUF022088
	for <qemu-devel@nongnu.org>; Fri, 11 Sep 2009 08:39:17 -0400
Subject: Re: [Qemu-devel] [PATCH 06/19] Add qemu_opts_validate() for post
	parsing validation
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <4AAA00A9.6070600@redhat.com>
References: <1252595941-15196-1-git-send-email-markmc@redhat.com>
	<1252595941-15196-7-git-send-email-markmc@redhat.com>
	<4AAA00A9.6070600@redhat.com>
Content-Type: text/plain
Date: Fri, 11 Sep 2009 13:38:11 +0100
Message-Id: <1252672691.20624.39.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: Mark McLoughlin <markmc@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org

On Fri, 2009-09-11 at 09:47 +0200, Gerd Hoffmann wrote:
> On 09/10/09 17:18, Mark McLoughlin wrote:
> > Several qemu command line options have a parameter whose value affects
> > what other parameters are accepted for the option.
> >
> > In these cases, we can have an empty description table in the
> > QemuOptsList and once the option has been parsed we can use a suitable
> > description table to validate the other parameters based on the value of
> > that parameter.
> 
> Hmm.  The "empty description" mode is intended to be used in case the 
> verification isn't done by QemuOpts at all (i.e. for -devices, where the 
> qdev property code will do the checks).  I really like to have the 
> option description hooked into QemuOptsList.
> 
> I can think of two possible ways to do that:
> 
> (1) We can stick all possible values info QemuOptsList->desc.  Then
>      have separate data structures to describe which fields are allowed
>      in which cases (and, while being at it, which fields are mandatory).

You'd need to make it part of the QemuOptDesc to make it easy to figure
out from reading the code which parameters apply to which types.

e.g. a QemuOptDesc::firstname_values field

> (2) We have multiple QemuOptDesc lists for the different cases.

As with what I did, you'll have some parameters which are common to
different types.

> I tend to prefer the first.  We can do the option parsing 
> unconditionally in qemu_opt_set() then and don't have two different 
> possible code paths for that.

Sounds reasonable, except it is nice that right now we have the
parameter descriptions associated with, and close to, the init function.

Cheers,
Mark.