From: Eric Van Hensbergen <ericvh@gmail.com>
To: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
Cc: Mike Wray <mike.wray@hp.com>,
xen-devel@lists.xensource.com,
"Ronald G. Minnich" <rminnich@lanl.gov>,
Eric Van Hensbergen <ericvh@users.sourceforge.net>
Subject: Re: Re: Interdomain comms
Date: Sat, 7 May 2005 16:29:07 -0500 [thread overview]
Message-ID: <a4e6962a050507142932654a5e@mail.gmail.com> (raw)
In-Reply-To: <1115486227.4082.70.camel@localhost>
On 5/7/05, Harry Butterworth <harry@hebutterworth.freeserve.co.uk> 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
next prev parent reply other threads:[~2005-05-07 21:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-05 15:18 please help: initialize XEND for my debug-FE/BE.c Aggarwal, Vikas (OFT)
2005-05-05 20:37 ` Harry Butterworth
[not found] ` <427B20B9.1010101@hp.com>
2005-05-06 12:14 ` Interdomain comms Harry Butterworth
2005-05-06 13:39 ` Mark Williamson
2005-05-06 16:04 ` Ronald G. Minnich
2005-05-06 16:49 ` Eric Van Hensbergen
2005-05-06 23:13 ` Harry Butterworth
2005-05-07 0:19 ` Eric Van Hensbergen
2005-05-07 13:26 ` Harry Butterworth
2005-05-07 14:57 ` Eric Van Hensbergen
2005-05-07 16:15 ` Ronald G. Minnich
2005-05-07 17:10 ` Keir Fraser
2005-05-07 21:22 ` Eric Van Hensbergen
2005-05-07 17:17 ` Harry Butterworth
2005-05-07 21:29 ` Eric Van Hensbergen [this message]
2005-05-07 22:11 ` Harry Butterworth
2005-05-08 0:57 ` Eric Van Hensbergen
2005-05-08 8:19 ` Andrew Warfield
2005-05-08 15:27 ` Eric Van Hensbergen
2005-05-10 8:31 ` Mike Wray
2005-05-10 10:09 ` Andrew Warfield
2005-05-10 14:30 ` Mike Wray
2005-05-10 14:51 ` Harry Butterworth
[not found] ` <eacc82a405051008243195164c@mail.gmail.com>
2005-05-10 15:26 ` Andrew Warfield
2005-05-10 16:42 ` Harry Butterworth
2005-05-08 8:36 ` Harry Butterworth
2005-05-08 16:18 ` Eric Van Hensbergen
2005-05-08 17:48 ` Harry Butterworth
2005-05-06 16:57 ` Nivedita Singhvi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a4e6962a050507142932654a5e@mail.gmail.com \
--to=ericvh@gmail.com \
--cc=ericvh@users.sourceforge.net \
--cc=harry@hebutterworth.freeserve.co.uk \
--cc=mike.wray@hp.com \
--cc=rminnich@lanl.gov \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.