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: check for early failures of qemu-dm (

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxl: check for early failures of qemu-dm (v2)
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Mon, 16 Nov 2009 15:59:04 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 16 Nov 2009 07:53:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19201.27696.30222.232418@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: <19201.16668.970391.316245@xxxxxxxxxxxxxxxxxxxxxxxx> <4B016748.8050904@xxxxxxxxxxxxx> <19201.27696.30222.232418@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20091001)
Ian Jackson wrote:
Did you have the qemu-dm ready patch in qemu ?

This is not relevant because my qemu currently dies before it gets to
that point.  Stefano tested v1 of my patch and it worked for him.
it's not irrelevant. as heavy discuss before, fixing the ready problem fix the qemu died in the meantime problem too (not ideally since you end-up waiting timeout, but it does). what you did is just an optimisation of the qemu died problem, which leave one problem open.

No, it can't, because there is actual functionality in the
intermediate process.  The libxl_fork function is not provided for the
benefit of "providing wrapper for syscalls".  It is there to factor
out the common error handling for the two instances of fork in
you can have a middle process callback without any problem within the libxl_exec call.
Why is it necessary ?  Some applications have an event loop or SIGCHLD
handler which automatically reaps all children.  In such an
application in order to collect a child process exit status we need to
allow the application to look the process up in its own table of
reaped processes.
sounds a bit premature, since we don't even have such an application yet nor that we ever had in the past either.
The osdeps arrangements were broken and backwards.  We were compiling
them in on Linux, which isn't necessary.  It's not necessary on BSD
either, but BSD presumably barfed on it because it declared the system
asprintf without special handling.
no, otherwise the init ctx need to allocate itself the memory of the context, instead of having
the caller "allocate it" itself on the fct stack.

If you do that then libxl can't be linked dynamically.  We should talk
about this.
it *can* be linked dynamically. the only "shortcoming" is the context structure can't grow dynamically. the same happens to all structures that we use for argument passing.


Xen-devel mailing list

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