| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadloc
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
|
|
|
| |
|
Home