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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

A few random questions:

* Does XenIDC have any performance impact?
* Can it be compatible with the current ring interface, or does it imply 
incompatibility with the existing scheme? (i.e. is it an "all or nothing" 
patch?)
* Will it be able to leverage page transfers?

Cheers,
Mark

On Wednesday 02 November 2005 12:37, 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.
>
> Hopefully this helps to explain why I've split out the IDC functionality
> from my USB driver into a generic service.
>
> Harry.

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