[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xenstore.h clarifications



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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.