From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdLFD-0002zh-0Q for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:11:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdLF9-0006R7-QB for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:11:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdLF9-0006Qz-J7 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:11:51 -0400 Message-ID: <551C18C2.50306@redhat.com> Date: Wed, 01 Apr 2015 19:11:46 +0300 From: Marcel Apfelbaum MIME-Version: 1.0 References: <551AAD75.8090909@linux.vnet.ibm.com> <551B963E.9060800@gmail.com> <87oan8z1yw.fsf@blackfin.pond.sub.org> <551C05F0.3090502@redhat.com> <87k2xvonem.fsf@blackfin.pond.sub.org> In-Reply-To: <87k2xvonem.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , Tony Krowiak , qemu-devel@nongnu.org, =?windows-1252?Q?Andreas_F=E4rber?= On 04/01/2015 06:53 PM, Markus Armbruster wrote: > Marcel Apfelbaum writes: [...] >> I noticed something weird. I cannot actually create an instance of machine >> or get a reference to current_machine in order to query its properties! >> >> It seems that util/qemu-config is used by qemu-img which obviously >> does not have a current machine nor the means to create it. >> >> So I have no way to create QOM objects for introspection :(. > > You'd have to do something like > > desc[] = generic entries + the machine's entries > > where the latter is empty outside qemu proper. Hmm! So I will loose with some dignity. I'll keep the properties of the base "machine" on a static array and *only* per-machine properties dynamic and I loose them. > > For 2.3, I recommend to do *only* generic entries. Specifically, > *exactly* the entries we had before we cleared out > qemu_machine_opts.desc[]. I submitted: [PATCH for-2.3] util/qemu-config" fix regression of qmp_query_command_line_options which includes both base-machine/per-machine properties. Is it that bad? qmp can query it and even the new options will work if qmp decides to set them. Can you have a look? > [...] >>> Big job, though. >> You lost me... you are talking about QAPI that I have no knowledge about, >> and I still don't see how I can create instances of QOM objects in the context >> of qemu-config. > > Very high level summary: > > 0. We use QemuOpts to define our command line. The definition is > *incomplete*. The missing parts are left to code. > query-command-line-options can't see them. OK > > 1. You have a QemuOpts problem that is actually pretty common: how to > accept a few fixed parameters plus a bunch of parameters that are > specific to the value of one of the fixed parameters (the > discriminator, in your case "type"). Yes, but is more than that: per-type properties are not static, you cannot find them before creating an actual QOM object, and that is not possible. We could have a per-machine static options array that will be loaded at init time into object properties... ugly. > > 2. We've solved this in several different ways, and all of them make > query-command-line-options useless. Got it > > 3. Same problem exists in QMP, and we have a decent solution there, > based on QAPI. OK > > 4. We'll soon have QMP/QAPI introspection. And then we can query a 'living' object's properties > > 5. If we used a QAPI schema to define our command line, we could do a > more complete job (because it's more expressive), and we'd get > introspection basically for free. If the QAPI schema will include *all* properties *per* machine type, sure. > > 6. #5 would be a big job, though. > > Less confused now? Much better, thanks! Marcel > [...]