| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [Fwd: Re: Interdomain comms]
Harry Butterworth wrote:
I agree with that. I've attached what I sent out as the socket proposal.
Thinking about it though, I don't really see why the api can't use
the standard linux kernel 'struct sock' for the endpoints and 'struct sk_buff'
struct sock is very, very, large - and we need to be much more
memory-sensitive than mainline Linux. That does seem to
me to be overkill.
for the data. These are both very flexible structs and can hide a lot of
stuff. You need some struct for the addressing.
The sk_buffs could be allocated out of the ring messages to avoid
copying.
You can do this with smaller subsets of that struct, certainly.
Ideally, I think the API should be self-contained, independent of Linux
and not a derived work because equivalent function is going to be
required for other paravirtualized operating systems and it would be
good to be able to have a common code base.
Good point.
The extra features in my API are all there for a reason: transactions
with a request and response phase are convenient for the clients; the
three states for the connection allow bracketing of changes in the
availability of the resources that are of relevance to a specific client
without global coordination; I specifically included the guarantees
required to cope with stale communications; my sketch was expressed
independent of the existing linux code and my API is sufficiently
different from the well known sockets API that people won't get the two
APIs confused.
It will be cleaner to build an alternative virtual infrastructure
underneath, too.
thanks,
Nivedita
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home