Xenstore.h clarifications

Xenstore.h clarifications

[Razvan Cojocaru]

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.


Thanks,
Razvan

Re: Xenstore.h clarifications

[Ian Campbell]

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.

Ian.

Re: Xenstore.h clarifications

[Razvan Cojocaru]

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

Re: Xenstore.h clarifications

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Xenstore.h clarifications"):
> I think there's a pretty good chance that the same applies to xenstore
> connections made over the device/shared-ring interface.

Yes.

> 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.

>From the kernel's point of view everything is fine but of course the
protocol running through the socket would be quite messed up.  For
xenstore, while in theory you could take turns somehow, I don't think
suggesting that is sensible.

> 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?

Exactly, yes.

Thanks,
Ian.