Re: [Xen-devel] Re: Interdomain comms

[Eric Van Hensbergen <ericvh@xxxxxxxxx>]

On 5/7/05, Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> I agree it would work well, definitely better than the current code, but
> I don't think it's right for Xen because it precludes the kind of
> optimisations that are relevant to Xen but not Plan 9.
> 

I really don't see how they preclude any optimizations in Xen,
particularly with some sort of scatter/gather mechanism in place - the
9P API would be unchanged, just the link-layer would be a bit
different (so its not even a protocol change).

>
> but you still wouldn't get the ability to manipulate the meta-data of a 
> request in a stack of I/O applications and then do a direct transfer of the 
> bulk data from the source to the target.
> 

Not clear why this is the case.  It seems like you'd be able to do
this sort of thing in any sort of protocol where the data is distinct
from the rest of the operation encapsulation.  In fact, there are many
different forms of synthetic "filter file systems" within Plan 9 that
take advantage of just this property (the fact that the bulk data is
handled separately from the control data).

> 
> In any case, my proposal decouples the IDC API clients from the actual
> memory management implementation so different page-flipping behaviours
> could be evaluated without requiring code changes in the clients.
> 

Again, this sounds like a good thing.  A nice abstract interface which
is valid on all platforms for communicating on byte streams between
domains (not just to the controller, but between peer domains as well)
is exactly the sort of transport we would want to build 9P on, but it
really seemed (from your initial proposal) that you were constructing
interfaces for much more than that.  Its also not clear to me whether
having extensions built into the IDC protocol for doing network
transactions would be the right thing to do, it sounds like it would
add a lot of complexity to an otherwise simple core mechanism -- and
as I stated previously, I think simplicity is the ultimate goal of
such an interface.

         -eric

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