From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: Re: [PATCH] libxl: check for early failures of qemu-dm (v2) Date: Mon, 16 Nov 2009 15:59:04 +0000 Message-ID: <4B0176C8.6030005@eu.citrix.com> References: <19201.16668.970391.316245@mariner.uk.xensource.com> <4B016748.8050904@eu.citrix.com> <19201.27696.30222.232418@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <19201.27696.30222.232418@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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 > libxl.c. > 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. > yep >> 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. -- Vincent