[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [DRAFT 1] XenSock protocol design document
On Fri, 8 Jul 2016, David Vrabel wrote: > On 08/07/16 15:16, Stefano Stabellini wrote: > > > > http://pubs.opengroup.org/onlinepubs/7908799/xns/connect.html > > Are you really guaranteeing full POSIX semantics for all these calls? > And not say, POSIX-like except where Linux decides to differ because > POSIX is dumb? > > How is the guest (which expects the semantics of its own OS) going to > know that connect(2) to an external IP is going to behave differently to > say connect(2) to localhost? > > a) The difficulties in reconciling the differences in behaviour and > features between remoted system calls and local ones. > > b) The difficulty in fully specifying (and thus fully implementing) the > PV interface. I'll refrain from replying to these points because they are about the implementation, rather than the protocol, which it will be discussed separately when I manage to publish the design document of the drivers. I am confident we can solve these issue if we work together constructively. I noticed you are not making any suggestions on how to solve these issues, which is good form when doing reviews. I want to address the following point first: > c) My belief that most of the advantages of this proposal can be > achieved with smarts in the backend. By backend do you mean netfront/netback? If so, I have already pointed out why that is not the case in previous emails as well as in this design document. If you remain unconvinced of the usefulness of this work, that's OK, we can agree to disagree. Many people work on things I don't believe particularly useful myself. I am not asking you to spend any time on this if you don't believe it serves a purpose. But please let the rest of the community work constructively together. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |