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