Re: Re: [PATCH] libxl: check for early failures of qemu-dm (v2)

[Vincent Hanquez <vincent.hanquez@eu.citrix.com>]

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