Re: [PATCH] skeleton frontend/backend examples and a deadlock

[Rusty Russell <rusty@rustcorp.com.au>]

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