From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W863q-0002Qs-Mw for qemu-devel@nongnu.org; Tue, 28 Jan 2014 05:38:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W863k-00040N-JY for qemu-devel@nongnu.org; Tue, 28 Jan 2014 05:38:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W863k-000408-AM for qemu-devel@nongnu.org; Tue, 28 Jan 2014 05:38:24 -0500 Message-ID: <52E78007.5030506@redhat.com> Date: Tue, 28 Jan 2014 11:01:43 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20131223021900.GA17346@amosk.info> <87sis8qwh1.fsf@blackfin.pond.sub.org> In-Reply-To: <87sis8qwh1.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] fix/re-do query-command-line-options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Amos Kong Cc: Osier Yang , laine@redhat.com, libvir-list@redhat.com, qemu-devel , rjones@redhat.com, anthony@codemonkey.ws Il 28/01/2014 10:36, Markus Armbruster ha scritto: > I think the data you can usefully collect with this approach is > approximately the data getopt_long()[*] gets: list of named command line > options, and whether they take an argument. > > You can use this data to fill in options not covered by QemuOpts. This > is a definite improvement. > > It still falls short of fully solving the command line introspection > problem. > > However, I'm not into rejecting imperfect incremental improvements we > can have now in favor of perfect solutions we can maybe have some day. > Go right ahead with your incremental improvement! It depends. If we can agree on the following: (a) do not add non-QemuOpts options (we haven't for a while) (b) document the QemuOpts schema for -acpitable, -smbios, -netdev, -net. These options validate the options with OptsVisitor, so we could do without QemuOpts schema, but we know the schema won't bitrot because we never remove suboptions. (c) do not add any more QemuOpts options without a schema, and use -object instead. Then: (a) there is no need to cover non-QemuOpts options in query-command-line-options. libvirt can treat them as crystallized. (b) documenting the schemata is not harder than what Amos proposed. (c) schema inspection for objects remains a problem, but one that we need to solve anyway so it doesn't affect query-command-line-options. Do you agree? Paolo