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] [PATCH 3/4] libxl: add version_info function [and 1 more

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3/4] libxl: add version_info function [and 1 more messages]
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Mon, 19 Apr 2010 17:41:24 +0100
Cc: Andre Przywara <andre.przywara@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 19 Apr 2010 09:42:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19404.33570.623809.702106@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <4BCB76FD.1020103@xxxxxxx> <4BCB791E.7000204@xxxxxxx> <4BCC0F86.8090707@xxxxxxxxxxxxx> <19404.30856.176804.871256@xxxxxxxxxxxxxxxxxxxxxxxx> <4BCC7FC4.10800@xxxxxxxxxxxxx> <19404.33570.623809.702106@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100411 Icedove/3.0.4
On 19/04/10 17:21, Ian Jackson wrote:
Vincent Hanquez writes ("Re: [Xen-devel] [PATCH 3/4] libxl: add version_info 
function [and 1 more messages]"):
On 19/04/10 16:36, Ian Jackson wrote:
I don't think that's correct because memory allocated by libxl_sprintf
does not survive return from libxl into the caller.

It survives as long as the context is not ctx_free. i.e. if the data
need to preserve longer, they will have do be duplicated before freeing
the context.

This is sadly not a really tenable behaviour in the long term because
(a) a long-running caller does not want to free the context (and
necessarily reestablish xenstore connections etc. etc.) (b) the caller
may anyway not be able to free the context if doing so frees data they
are still using.

This is not perfect, and has a (tiny) cost, but it makes writing the current ocaml bindings (and the future python bindings) much easier and much less memory leak prone.

Limiting the number of possible boxes of error type, will definitely help getting XCP ported on libxl.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>