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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] Why xs_domain_open() in fs_backend
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Wed, 13 Oct 2010 20:20:00 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "gm281@xxxxxxxxx" <gm281@xxxxxxxxx>, "samuel.thibault@xxxxxxxxxxxxx" <samuel.thibault@xxxxxxxxxxxxx>
Delivery-date: Wed, 13 Oct 2010 05:22:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1010131128290.2423@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <789F9655DD1B8F43B48D77C5D30659732F9D7EBD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20101013084739.GF4007@xxxxxxxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659732F9D7FA3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20101013092439.GH4007@xxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1010131128290.2423@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Actqwdo/M9AHNx7VQz6JWRn5+i4U0QADgVrg
Thread-topic: [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;
>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