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

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



>-----Original Message-----
>From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
>Sent: Wednesday, October 13, 2010 6:31 PM
>To: Tim Deegan
>Cc: Jiang, Yunhong; xen-devel@xxxxxxxxxxxxxxxxxxx; gm281@xxxxxxxxx;
>samuel.thibault@xxxxxxxxxxxxx
>Subject: 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.

But are their ussage covers the xs_watch? Seems xs_read/xs_write works well in 
the fs-backend utility. Only xs_watch has such issue.

>>
>
>minios exports xs_daemon_open and xs_daemon_close

The minios implementation seems a bit different.
In fact, I'm very confused why fs-backend failed on my environment. It is a 
tools for stubdom qemu and I assume it should be used by a lot of people, and I 
didn't google out any complain on this issue.
Maybe my environment cause such issue? Can anyone else have a try also? Simply 
input "fs-backend" should invoke it.

Thanks
--jyh

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