[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |