harry
2005-Nov-04 17:06 UTC
[Fwd: Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock]
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2005-Nov-04 17:15 UTC
Re: [Fwd: Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock]
Another question: XenIDC is designed to handle indirection over the network, etc, right? Would it be possible to make the indirection transparent to the guest by implementing it in the backend? Or would that be the job of the frontend? It certainly seems cleaner to me to make this as transparent to the guest as possible - also reduces guest complexity. Cheers, Mark On Friday 04 November 2005 17:06, harry wrote: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
harry
2005-Nov-04 17:41 UTC
Re: [Fwd: Re: [Xen-devel] [PATCH] skeleton frontend/backend examples and a deadlock]
On Fri, 2005-11-04 at 17:15 +0000, Mark Williamson wrote:> Another question: > > XenIDC is designed to handle indirection over the network, etc, right? Would > it be possible to make the indirection transparent to the guest by > implementing it in the backend? Or would that be the job of the frontend?The API is designed to be _compatible with a network transparent implementation_ which means that you should be able to change the implementation to one that worked over a network without having to change any of the clients of the API (BE or FE). The current implementation of the API is based on xenbus and grant tables and is restricted to a single machine. If you wanted to make a network transparent implementation of the API you could do it pretty much however you wanted. I''d probably do it by having code in both the FE and the BE since that would avoid having to context switch to a BE domain on the FE node before going over the network.> > It certainly seems cleaner to me to make this as transparent to the guest as > possible - also reduces guest complexity.You could do it all in the BE if you wanted. In either case, you shouldn''t have to change any of the driver code.> > Cheers, > Mark > > On Friday 04 November 2005 17:06, harry wrote: >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel