From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W87QM-0001A7-T7 for qemu-devel@nongnu.org; Tue, 28 Jan 2014 07:05:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W87QF-0006YH-LF for qemu-devel@nongnu.org; Tue, 28 Jan 2014 07:05:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W87QE-0006YC-U4 for qemu-devel@nongnu.org; Tue, 28 Jan 2014 07:05:43 -0500 Message-ID: <52E79D0F.2080200@redhat.com> Date: Tue, 28 Jan 2014 13:05:35 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20131223021900.GA17346@amosk.info> <87sis8qwh1.fsf@blackfin.pond.sub.org> <52E78007.5030506@redhat.com> <87iot4jp6r.fsf@blackfin.pond.sub.org> In-Reply-To: <87iot4jp6r.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 Cc: Osier Yang , libvir-list@redhat.com, rjones@redhat.com, qemu-devel , laine@redhat.com, anthony@codemonkey.ws, Amos Kong Il 28/01/2014 12:55, Markus Armbruster ha scritto: > 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. We can add it under an existing QemuOpts group or invent a new one (like we did for -rt or -msg). > However, we need to somehow stuff those into QemuOpts anyway, so > -readconfig / -writeconfig can cover them. Yep. >> (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? -device already provides its own introspection via "qom-list-types" and "-device driver,?". -object doesn't have an equivalent of "-device driver,?", but that's a separate problem. >> (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? There are some: - legacy slirp options -tftp/-bootp/-redir/-smb - -enable-fips is what triggered this discussion, but we found another solution in Libvirt - -tpmdev is enabled only if CONFIG_TPM, but its presence can be queried via qom-list-types too. >> (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*. Note the "doesn't affect query-command-line-options" part. Amos's patch do not solve the problem of which classes can be instantiated with -object, or of which properties can be used. Paolo >> Do you agree? > > It depends :) >