This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Why xs_domain_open() in fs_backend

On Wed, 13 Oct 2010, Tim Deegan wrote:
> At 10:13 +0100 on 13 Oct (1286964818), Jiang, Yunhong wrote:
> > When I firstly checking the code, I also think the xs_domain_open()
> > should be more approprate. But it is a bit surprise that it is not
> > used at all, except one utility , xentore-client.c , in xenstore
> > directory, which definitely not need this (I assume xenstore-ls should
> > always be in same domain as xenstore daemon).  I suspect if
> > xs_domain_open() and the xenfs is really widely tested.
> I had thought it was used by stubdom qemu, but it seems not - not sure
> how that works then.  It isn't specifically tested but I know that some
> people have been using it successfully in the last month or two.

minios exports xs_daemon_open and xs_daemon_close

> > >
> > >(IMHO xs_daemon_open() should be killed entirely, but there are some
> > >dom0 kernels where the xs_domain_open() connection isn't allowed to send
> > >XS_INTRODUCE commands.  That shouldn't make a difference here, though).
> > 
> > But we should at least add xs_domain_close() firstly, matching
> > xs_domain_open() with xs_deamon_close() is really something strange :-)
> I think the right thing to do would be have xs_daemon_open hide the
> details of whether the connection is over a socket or xenbus, and not
> have every caller have to care about that.


Xen-devel mailing list