From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W88pc-0001GL-DA for qemu-devel@nongnu.org; Tue, 28 Jan 2014 08:36:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W88pL-0006k4-Is for qemu-devel@nongnu.org; Tue, 28 Jan 2014 08:36:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W88pL-0006jy-A6 for qemu-devel@nongnu.org; Tue, 28 Jan 2014 08:35:43 -0500 Message-ID: <52E7B227.2060408@redhat.com> Date: Tue, 28 Jan 2014 14:35: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> <52E79D0F.2080200@redhat.com> <8761p4gsbk.fsf@blackfin.pond.sub.org> In-Reply-To: <8761p4gsbk.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 , laine@redhat.com, libvir-list@redhat.com, rjones@redhat.com, qemu-devel , anthony@codemonkey.ws, Luiz Capitulino , Amos Kong Il 28/01/2014 14:16, Markus Armbruster ha scritto: >>> 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). > > Do you mean -rtc? I meant -rt, but -rtc applies just as well. :) > -msg takes a timestamp=on/off argument. I guess that doesn't feel too > forced, because we could conceivably have more settings related to error > reporting. > > Do you mean to suggest new options should always be done in a way that > makes them fit into QemuOpts? Yes. Not into *existing* QemuOpts of course. > How would you add something like -S, -nodefaults, or -daemonize? I would add -nodefaults and -S to -machine. I would deprecate -daemonize. But that's just for the sake of -readconfig. Consumers of introspection can just "know" that those options are there. > The question is whether we should extend QemuOpts to cover options > without arguments, or change the options without arguments to fit into > existing QemuOpts, e.g. by making them all syntactic sugar for a > suitable QemuOpts-style option. > > If we do the latter, we need to tell customers of command line > introspection to look only for the desugared forms. Yeah. >>>> (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,?". > > We're discussing introspection via QMP, so "-device driver,help" doesn't > count. > > qom-list-types with argument "implements": "device" together with > device-list-properties indeed lets you introspect device models and > their properties. You then need to to know how to translate that to > the command line. For instance, you need to know that "type": "on/off" > in the former means "type": "boolean" in the latter, and so forth. Yes. That's what I actually meant. O:-) > What I'd like to see is more unified introspection, not this smattering > of one-offs hacked up without too much thought to serve some immediate > need we have now. > > We already have something that aspires to be our unified interface > description: QAPI schemata. Perhaps we should make it our unified > introspection mechanism while we're at it. QOM introspection can use QAPI schemata. Property types should be one of: * child * link * QAPI scalar type * QAPI compound type I see QOM introspection as orthogonal to QAPI introspection, and QemuOpts introspection as complementary to both: command line introspection QMP introspection | | | | | v | | v QOM introspection <--' | QemuOpts | | introspection v | QAPI introspection <-----------' Makes any sense? :) >>>> (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. > > Possible misunderstanding on my part. I was afraid you were arguing to > solve -object introspection *instead* of Amos's incremental improvement, > but that doesn't seem to be the case. Well, I was arguing against this series. I think it provides little benefit and has a comparatively high cost in terms of future backwards compatibility. I was arguing for ignoring non-QemuOpts options and focus on what really matters, which is QemuOpts, QOM and QAPI introspection. The first is already there and can be fixed by adding schemata for -acpitable and friends. QAPI introspection is already being tackled by Amos. QOM/-object is indeed the elephant in the room, but luckily we have enough few users that I believe we can do it if we agree on the right design. Paolo