[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Interdomain comms
On 5/6/05, Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > I skimmed what I could find immediately on 9P: > http://www.cs.bell-labs.com/sys/man/5/INDEX.html and came to the > conclusion that what I proposed is lower level and more general (it's > also simpler but, given that it's not doing the same thing, that isn't > really significant). There isn't a great deal of detail on the specifics of the protocol beyond the man pages. I think you'll find the following Plan 9 foundational papers more illustrative of the type of things that it can be used to do: http://plan9.bell-labs.com/sys/doc/9.pdf http://plan9.bell-labs.com/sys/doc/names.pdf and in particular: http://plan9.bell-labs.com/sys/doc/net/net.pdf For the security minded: http://plan9.bell-labs.com/sys/doc/auth.pdf I believe Ron's original statements were motivated by your earlier statement: >> >>The event-channel and shared memory page are fine as low-level >>primitives to implement a comms channel between domains on the same >>physical machine. The problem is that the primitives are unnecessarily >>low-level from the client's perspective and result in too much >>per-client code. >> This is exactly the sort of thing that the Plan 9 networking model was designed to do. The idea being that the Plan 9 model provides a nice abstract layer which to communicate with AND to organize (the organization is an important feature) the resulting communication channels and endpoints (no matter what the underlying transport is or where the particular endpoints may be). The Plan 9 networking model can be run over named pipes, shared memory, PCI buses, Ethernet, Infiniband, or whatever other flavor of network with relatively minor requirements on the underlying transport layer. > > You could implement 9P on top of my IDC API proposal > You could implement 9P on top of such an IDC API, however, it seems like it would add unnecessary overhead. 9P can be easily implemented directly on top of the existing event/shared-page mechanisms and then trivially bridged to the network at the I/O partition(s). As far as multi-level protocol stacks and circumventing data paths, I'd hope we could come up with a simpler, more elegant solution. Looking over your earlier proposal it seems like an awful lot of complexity to accomplish a relatively simple task. Perhaps the refined API will demonstrate that simplicity better? I'd be really interested in the security details of your model as well when you finish the more detailed proposal. >> >>The inter-domain communication API should preserve the efficiency of >>these primitives but provide a higher level API which is more convenient >>to use. >> I think this is a great mission statement -- convenience and simplicity are the key to selling such an API. I'd suggest we step through a complete example with actual applications and actual devices that would demonstrate the problem that we are trying to solve. Perhaps Ron and I can pull together an alternate proposal based on such a concrete example. -eric _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |