[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.