WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] libxl, Introduce a QMP client
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 6 Jun 2011 19:31:09 +0100
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 06 Jun 2011 11:28:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307375125.775.479.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Mon, 6 Jun 2011, Ian Campbell wrote:
> I think we should try where possible to keep this stuff entirely within
> libxl. The existing libxl event API is a bit of a mess but I think if it
> were cleaned up (IanJ has a plan I think) then it would be the right
> place to integrate the libxl and caller event loops.
> 
> For the time being though I think libxl should provide the fd and not
> expect the caller to construct the path and open it etc. IOW
> libxl_qmp_initialize should not take a socket option, it should
> construct the path, do the open internally and return the fd.

I agree on this.

Libxl needs to use QMP internally for things like the serial. Libxl
cannot rely on the caller (xl) to select on the fd and call
libxl_qmp_do_next later for libxl to put the appropriate serial device
on xenstore.
Ideally QMP should be completely hidden inside libxl.

I think all the initialization details should be handled internally by
libxl_domain_create_new, including opening the QMP connection and
reading back the serial device.

After that libxl should probably expose a single event driven mechanism,
both for xenstore and QMP, with some opaque callbacks in the QMP case.
However this could be done together with the libxl events refactoring
that Ian wants to do.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel