This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] libxl, Introduce a QMP client

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxl, Introduce a QMP client
From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Date: Tue, 7 Jun 2011 16:50:23 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 07 Jun 2011 08:51:32 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=oTI9o4W97Z8r8RIkpdOQabaotqkiABI5Tb3v+j/4yFc=; b=KJTC6O1cRTggbIMf0U0uaGtV1KzZchACfNtWVlPPFYWr2CJzg/mcWgX4hltzzUd8U2 3MR32XZKQCYhmzLZ8OV/i9eC7N0xrdc4QkaGKnVrgJCYb+q10JUxNvypReMGXugbojQS TrWvHoQmEzOgUawpf8dQx0bUza6tsBZhumlKo=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Swz7nIgQL68S6TCCZ8lQYUyCj9b8/OqHbZBlbCNCTqSyOyUccchlrbCvVT7STTyXMp +wSwU8517UPA7SPwzNJhLYohOI50gkqL8rOL0TYVfuIgjJfhl9JXnMlNo++tOFFgDmLH xTopUwuRMAG7T89HV64KrpV7qqGn+sY2oAERY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307457041.775.639.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1307366804-310-1-git-send-email-anthony.perard@xxxxxxxxxx> <1307375125.775.479.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106061918320.12963@kaball-desktop> <1307437086.775.508.camel@xxxxxxxxxxxxxxxxxxxxxx> <BANLkTikCPAMren1Nk4KcwtJ315vS5=1d4A@xxxxxxxxxxxxxx> <1307457041.775.639.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Jun 7, 2011 at 15:30, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>> Actually, QEMU doesn't seem to handle more than one client at a time
>> with a single socket.
> That seems like a pretty obvious short coming, do you know if it is a
> deliberate policy or just a case of not implemented yet?

I think it because they use the same "char device" code to handle by
example the serial port or the monitor (including QMP). So when a
client is connected, there just stop to handle the listenning fd until
the client disconnects itself.

>>  For more client, we can always open more than
>> one QMP server with different path/port. In this case, they will be
>> handle separately by QEMU.
> Problem is determining the correct number to create when we start qemu.

Well, a simple answer would be two, one to listen the event from QEMU,
if we need to do that, and the second one would be for the commands,
one at a time, and libxl close the socket. If a command socket is
already in use, then another libxl client whose trying to connect to
the same socket will wait until QEMU accept the connection.

Anthony PERARD

Xen-devel mailing list