From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTVnb-0002gi-Ry for qemu-devel@nongnu.org; Wed, 22 Jul 2009 02:59:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTVnW-0002gT-5U for qemu-devel@nongnu.org; Wed, 22 Jul 2009 02:59:34 -0400 Received: from [199.232.76.173] (port=39437 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTVnW-0002gE-2j for qemu-devel@nongnu.org; Wed, 22 Jul 2009 02:59:30 -0400 Received: from mx20.gnu.org ([199.232.41.8]:9520) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTVnV-0001jk-FZ for qemu-devel@nongnu.org; Wed, 22 Jul 2009 02:59:29 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTVnU-0004b5-Ce for qemu-devel@nongnu.org; Wed, 22 Jul 2009 02:59:28 -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 n6M6xOTG001358 for ; Wed, 22 Jul 2009 02:59:25 -0400 Message-ID: <4A66B8AD.90107@redhat.com> Date: Wed, 22 Jul 2009 08:58:53 +0200 From: Gerd Hoffmann 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> <4A65E5AB.1030506@redhat.com> In-Reply-To: <4A65E5AB.1030506@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org On 07/21/09 17:58, Kevin Wolf wrote: > 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. -net is a very special beast as the list of parameters is very different for -net nic, -net tap, -net user, ... So it probably makes sense to have a separate QemuOptsList for each of them instead of storing a "type=[nic|tap|user]" into a common net list. >> 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. Yep, so we have one place where we catch parse errors instead of having each callsite to check for qemu_opt_get_$type() failures. cheers, Gerd