From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W87Gi-0005S2-Ke for qemu-devel@nongnu.org; Tue, 28 Jan 2014 06:55:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W87Gc-0003Kj-Fd for qemu-devel@nongnu.org; Tue, 28 Jan 2014 06:55:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W87Gb-0003KX-P6 for qemu-devel@nongnu.org; Tue, 28 Jan 2014 06:55:46 -0500 From: Markus Armbruster References: <20131223021900.GA17346@amosk.info> <87sis8qwh1.fsf@blackfin.pond.sub.org> <52E78007.5030506@redhat.com> Date: Tue, 28 Jan 2014 12:55:40 +0100 In-Reply-To: <52E78007.5030506@redhat.com> (Paolo Bonzini's message of "Tue, 28 Jan 2014 11:01:43 +0100") Message-ID: <87iot4jp6r.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] fix/re-do query-command-line-options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Osier Yang , libvir-list@redhat.com, rjones@redhat.com, qemu-devel , laine@redhat.com, anthony@codemonkey.ws, Amos Kong Paolo Bonzini writes: > 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) That would mean we can't ever add an option that doesn't take an argument again. However, we need to somehow stuff those into QemuOpts anyway, so -readconfig / -writeconfig can cover them. > (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. -device? > (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. Some options are undef #ifdef. That's actually a good idea, because it permits finding out which options are available via command line introspection. Now, what if a non-QemuOpts option is under #ifdef? I haven't checked... Even if there isn't one now, are we ready to give up the ability to do that for good? > (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. As long as we don't have such schema inspection, I'm rather reluctant to reject alternative means to solve problems people have *now*. > Do you agree? It depends :)