Re: Xenstore.h clarifications

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 11/28/2014 11:58 AM, Ian Campbell wrote:
> On Thu, 2014-11-27 at 12:51 +0200, Razvan Cojocaru wrote:
> 
> It's a good idea to CC the relevant maintainers if you want their input.
> 
>> Hello,
>>
>> I know that xc_interface_open() can be safely called several times from
>> the same process, and that several processes can each have a bunch of
>> xc_interface handles open, and that I shouldn't use an xc_interface
>> inherited from the parent in a child process, because xenctrl.h says so.
>>
>> Is it safe to assume that the same restrictions / conventions apply to
>> xs_handles obtained via xs_open()? Xenstore.h is not explicit. Looking
>> at the code, it would seem safe to assume that it can be used in a
>> similar manner, but it would be nice to have this confirmed if possible.
> 
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.
> 
> I'm not really sure about the semantics of a Unix domain socket after a
> fork, but I don't expect both parent and child could sanely make use of
> it.
> 
> So I think the answer is:
> 
>       * Connections made with xs_open(0) (which might be shared page or
>         socket based) are only guaranteed to work in the parent after
>         fork.
>       * Connections made with xs_open(XS_OPEN_SOCKETONLY) will be usable
>         in either the parent or the child after fork, but not both.
>       * xs_daemon_open*() and xs_domain_open() are deprecated synonyms
>         for xs_open(0)
>       * XS_OPEN_READONLY has not bearing on any of this.
> 
> Ian, does that seem right?
> 
> Razvan, assuming Ian concurs with the above (or corrects it) then could
> you knock up a patch to document the result please.

Sure, I'll document whatever gets confirmed.


Thanks,
Razvan