From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38366)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1WGrEc-0003aj-K6
	for qemu-devel@nongnu.org; Fri, 21 Feb 2014 09:37:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1WGrEW-0003Jc-Kj
	for qemu-devel@nongnu.org; Fri, 21 Feb 2014 09:37:50 -0500
Received: from mx1.redhat.com ([209.132.183.28]:21517)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1WGrEW-0003JY-Bm
	for qemu-devel@nongnu.org; Fri, 21 Feb 2014 09:37:44 -0500
Message-ID: <530764B0.40500@redhat.com>
Date: Fri, 21 Feb 2014 15:37:36 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20140221091629.GE11907@stefanha-thinkpad.redhat.com>
	<CA+aC4kubVf1sVCQQGRWEpP7+ZA33WSCB1TEjjC_XveKidNXCRw@mail.gmail.com>
In-Reply-To: <CA+aC4kubVf1sVCQQGRWEpP7+ZA33WSCB1TEjjC_XveKidNXCRw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QOM vs QAPI for QMP APIs
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: Andreas Faerber <afaerber@suse.de>, Luiz Capitulino <lcapitulino@redhat.com>, qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>, Michael Roth <mdroth@linux.vnet.ibm.com>

Il 21/02/2014 15:29, Anthony Liguori ha scritto:
> On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>> I need to add a QMP API that lists dataplane threads.  This is similar
>> to "query-cpus" where the thread IDs are reported.  It allows the client
>> to bind threads to host CPUs.
>>
>> I'm inclined to add a "query-iothreads" QMP command:
>>  * It's easy to implement using QAPI
>>  * We've developed best practices for QMP APIs
>>  * We know how to version and make QMP APIs extensible
>>  * Clients (including libvirt) are used to QMP JSON RPC
>>
>> But maybe I should use QOM instead:
>>  * Add a "qom-find-objects-by-class" QMP command (Paolo's idea)
>>  * Client does "qom-find-objects-by-class IOThread /objects"
>>  * Client then uses "qom-get" to fetch the thread_id property on each
>>    IOThread object
>>  * But we haven't really established how QOM APIs will work
>
> I have no objection to introducing a QMP command.
>
> I think qom-find-objects-by-class is a reasonable approach but I would
> also consider just grouping all of the IOThreads in a well known path
> instead of just having them live in /objects.  So something like
> /objects/threads/thread0/pid.

/objects is the namespace for -object, but a similar idea is that 
objects could create links of themselves under other paths.  So you 
would have /threads where you can list iothread objects or /backend/rng 
for RNG backends.

Still Stefan doesn't like the idea of sending O(n) commands to query the 
thread ID of n iothread objects.

Paolo