From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JzAEL-0000te-56 for qemu-devel@nongnu.org; Thu, 22 May 2008 08:49:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JzAEJ-0000q4-1q for qemu-devel@nongnu.org; Thu, 22 May 2008 08:49:12 -0400 Received: from [199.232.76.173] (port=39391 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JzAEI-0000pr-KZ for qemu-devel@nongnu.org; Thu, 22 May 2008 08:49:10 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:54077) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JzAEI-0002Lj-7H for qemu-devel@nongnu.org; Thu, 22 May 2008 08:49:10 -0400 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate02.web.de (Postfix) with ESMTP id C749BDDCBC61 for ; Thu, 22 May 2008 14:49:08 +0200 (CEST) Received: from [88.64.5.207] (helo=[192.168.1.198]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1JzAEG-0000pP-00 for qemu-devel@nongnu.org; Thu, 22 May 2008 14:49:08 +0200 Message-ID: <48356BC4.3090805@web.de> Date: Thu, 22 May 2008 14:49:08 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <48336413.2060909@web.de> <18485.18619.634431.859466@mariner.uk.xensource.com> In-Reply-To: <18485.18619.634431.859466@mariner.uk.xensource.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24B822B6850CD31427BAB558" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 1/3] Modular command line options Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig24B822B6850CD31427BAB558 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ian Jackson wrote: > Jan Kiszka writes ("[Qemu-devel] [PATCH 1/3] Modular command line optio= ns"): >> Following up on my earlier proposal to introduce per-machine command >> line options, this version provides a more generic approach. It should= >> also be usable for scenarios like per-arch or per-accelerator. >=20 > I approve of splitting the code up like this, and having a > table-driven parsing arrangement. But ideally we could get rid of > `index' and the giant switch() statements too. Something more like >=20 > typedef void QEMUOptionParser(struct QEMUOption *option, const char *= optarg); >=20 > typedef struct QEMUOption { > const char *name, *helpstring; > QEMUOptionParser handler; > int flags; Ack. This just enforces a bit more effort to convert the existing opts... :-> > int int_for_handler; > void *void_for_handler; I don't think there is an need for both. A plain void *parser_opaque; should suffice as the user can perfectly typecast the void to int. > } QEMUOption; >=20 > qemu_register_option_set(const QEMUOption *options); Here I would then suggest qemu_register_option_set(const char *set_name, const QEMUOption *options); to save the chance for visually grouping options. >=20 > We pass the QEMUOption* to the parser handler so it can see the > canonical name and any extra stuff put in the option structure. > and in vl.c you'd do something like this: >=20 > static const QEMUOption basic_options[]=3D { > ... > { "hda", opthandler_drive, 0, 0 }, > { "hdb", opthandler_drive, 0, 1 }, > { "hdc", opthandler_drive, 0, 3 }, > { "hdd", opthandler_drive, 0, 4 }, > ... > { 0 } /* null entry is required to terminate the table */ > } >=20 > qemu_register_option_set(basic_options); >=20 > The linked list of option tables is private to the option parser. Good idea. Then the structure should look like this: struct QEMUOptionSet { const char *name; const QEMUOption *options; struct QEMUOptionSet *next; }; OK, as this version would require even more refactoring, please let us agree on the critical data structures first. Specifically, this takes an ack from the maintainers. Jan PS: The element set of a future config file format could perfectly grow with each QEMUOption registered to the core. So I also see no conflict of this effort with the config file specification work. --------------enig24B822B6850CD31427BAB558 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFINWvEniDOoMHTA+kRAoRiAJ9vogfNcO7ciGHqSRWxxpi6cxupoACdHmVA mWjW5wQ1LZb5ZrsrA7KIhd8= =1fCX -----END PGP SIGNATURE----- --------------enig24B822B6850CD31427BAB558--