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


[Xen-tools] Re: [Fwd: Question about use of xenstore]

To: harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-tools] Re: [Fwd: Question about use of xenstore]
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Wed, 10 Aug 2005 13:14:53 +1000
Cc: xen-tools@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 Aug 2005 03:13:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1123594317.16359.12.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
References: <1123594317.16359.12.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2005-08-09 at 14:31 +0100, harry wrote:
> CC Anthony and the list...

Damn me and my serial mail reading... Re-transmitting reply:

On Tue, 2005-08-09 at 14:03 +0100, harry wrote:
> What is the intended style of use for xenstore when controlling the
> sequencing of operations?  For example, when I unload my USB FE driver
> module I need to make sure that the BE driver has finished with the
> shared memory before the FE frees it back to the FE kernel.

Good question.  For the block driver, we cannot have outstanding
requests when the device goes away, so this isn't a problem.

The simplest solution is to wait until the backend is deleted from the
store (your frontend will usually be watching the backend for changes
anyway) before freeing the page.  This is a little messy because your
driver structure will be freed by the bus before this, but not too bad.

For block drivers, it works like this:
1) tool deletes frontend dir
2) frontend domain: xenbus calls driver cleanup
3) backend domain: sees frontend go away and deletes backend dir, calls
xenbus to do driver cleanup.

That model seems to work well, and requires very little from the tools.
I would recommend pursuing the same model for USB, although your
frontend driver cleanup would leave the watch active, and page mapped,
waiting to see that final backend delete.

Hope that clarifies!
A bad analogy is like a leaky screwdriver -- Richard Braakman

Xen-tools mailing list