From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTWJX-0005BG-9I for qemu-devel@nongnu.org; Wed, 22 Jul 2009 03:32:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTWJS-00057H-3n for qemu-devel@nongnu.org; Wed, 22 Jul 2009 03:32:34 -0400 Received: from [199.232.76.173] (port=42344 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTWJR-00057B-Mm for qemu-devel@nongnu.org; Wed, 22 Jul 2009 03:32:29 -0400 Received: from mx20.gnu.org ([199.232.41.8]:12537) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTWJQ-0005Qv-Hu for qemu-devel@nongnu.org; Wed, 22 Jul 2009 03:32:28 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTWJN-0006Xe-Rg for qemu-devel@nongnu.org; Wed, 22 Jul 2009 03:32:26 -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 n6M7WNNZ011837 for ; Wed, 22 Jul 2009 03:32:23 -0400 Message-ID: <4A66C040.8010204@redhat.com> Date: Wed, 22 Jul 2009 09:31:12 +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> <4A65E5AB.1030506@redhat.com> <4A66B8AD.90107@redhat.com> In-Reply-To: <4A66B8AD.90107@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/21/09 17:58, Kevin Wolf wrote: >> 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. I agree, -net should be done different, so this was a bad example. But I thought we had more of them. -boot is an option with implicit first parameter name, and there was at least a discussion on making -smp another one. There might be more. Or do you want to keep the old parsing code for these options? >>> 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. Sounds great. Now it just needs to be implemented. ;-) Kevin