RE: [Xen-devel] Why xs_domain_open() in fs_backend
>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;
>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.
>> > >
>> > >(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