WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadloc

To: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Thu, 03 Nov 2005 12:36:52 +1100
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, mark.williamson@xxxxxxxxxxxx
Delivery-date: Thu, 03 Nov 2005 01:33:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1130935066.4719.22.camel@localhost>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1130908964.18258.25.camel@xxxxxxxxxxxxxxxxxxxxx> <1130935066.4719.22.camel@localhost>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2005-11-02 at 12:37 +0000, Harry Butterworth wrote:
> On Wed, 2005-11-02 at 16:22 +1100, Rusty Russell wrote:
> > Here are example frontend and backend driver skeletons.  They're
> > *designed* to handle driver restart and module unloading.  However,
> > device_unregister deadlocks.  I guess noone tried testing
> > unregister_xenbus_watch when not called from a watch callback.
> 
> Thanks, that'll be useful for me to know when it comes to testing my
> code.
> 
> For comparison, I've knocked up a skeleton FE/BE driver based on the
> xenidc API that I'm using for my USB driver.
> 
> You'll see that my patch is smaller, simpler and provides significantly
> more functionality: enough to send messages and transactions
> bi-directionally between the FE and BE.  For a fair comparison, yours
> would require interrupt handlers, use of the RING macros, correct memory
> barriers etc.

Agreed!  These drivers are a clear demonstration that the current xenbus
device API is too low-level.

More obvious than putting a layer on top of the xenbus API was to change
the xenbus API to be more convenient.  But when I tried to rewrite the
xenbus API, I realised I would have had to rewrite every driver, and it
doesn't get much nicer anyway.

A connection-oriented API seems an obviously-good idea to me.
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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