From mboxrd@z Thu Jan 1 00:00:00 1970 From: harry Subject: Re: [Fwd: Re: [PATCH] skeleton frontend/backend examples and a deadlock] Date: Fri, 04 Nov 2005 17:41:22 +0000 Message-ID: <1131126082.3019.22.camel@localhost.localdomain> References: <1131123986.3019.7.camel@localhost.localdomain> <200511041715.43051.mark.williamson@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200511041715.43051.mark.williamson@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Williamson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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: >