From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTHkx-0002eg-2v for qemu-devel@nongnu.org; Tue, 21 Jul 2009 11:59:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTHku-0002aU-CM for qemu-devel@nongnu.org; Tue, 21 Jul 2009 11:59:54 -0400 Received: from [199.232.76.173] (port=52439 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTHks-0002Zq-7g for qemu-devel@nongnu.org; Tue, 21 Jul 2009 11:59:50 -0400 Received: from mx2.redhat.com ([66.187.237.31]:55653) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTHkq-0003Gj-TK for qemu-devel@nongnu.org; Tue, 21 Jul 2009 11:59:49 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n6LFxmAN022974 for ; Tue, 21 Jul 2009 11:59:48 -0400 Message-ID: <4A65E5AB.1030506@redhat.com> Date: Tue, 21 Jul 2009 17:58:35 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v3 4/5] QemuOpts: framework for storing and parsing options. References: <1247756224-19219-1-git-send-email-kraxel@redhat.com> <1247756224-19219-5-git-send-email-kraxel@redhat.com> <4A602234.50208@redhat.com> <4A65C9B1.8090200@redhat.com> In-Reply-To: <4A65C9B1.8090200@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Gerd Hoffmann schrieb: > On 07/17/09 09:03, Kevin Wolf wrote: >> Gerd Hoffmann schrieb: >>> This stores device parameters in a better way than unparsed strings. >>> >>> New types: >>> QemuOpt - one key-value pair. >>> QemuOpts - group of key-value pairs, belonging to one >>> device, i.e. one drive. >>> QemuOptsList - list of some kind of devices, i.e. all drives. >> What about having the options typed like I did in qemu-option.[ch]? >> >> In general qemu-option seems to do more parsing/checking than QemuOpts >> does, on the other hand it's not yet generic enough to suit everything. > > Yup, qemu-options has all in one struct, which fails on multiple > instaces (i.e. two drives). Right, this is one of the points I thought of. Another one is that there are some variants in use with a required first parameter that doesn't have a name (like nic in -net nic,model=xyz). I guess, there are some more details that are not completely covered. >> Maybe a combination of both would be the right thing? > > I think the question is here how and when we want to do the parsing. > > We could do it early, when parsing/storing the values. QemuOptsList > could get a QEMUOptionParameter-like struct instead of the simple > valid[] array. QemuOpts->value would become a union. qemu_opt_set > handles parsing and stores in the union. qemu_opt_get() would move to > qemu_opt_get_$type() and it would return the value from the matching > union member. > > We could do it late, when using the values. Parsing would happen > directly in qemu_opt_get_$type(). I would prefer doing it in a central place, so that you don't depend on the user to actually trigger checks. But probably both would work. Kevin