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

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

ditto




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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