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
|
Home