On 5/23/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Wednesday 23 May 2007, Eric Van Hensbergen wrote:
> > On 5/23/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
> > >
> > > For me, plan9 does provide answers to a lot of above requirements.
> > > However, it does not provide capabilities for shared memory and it
> > > adds extra complexity. It's been designed to solve a different problem.
> > >
> > As a point of clarification, plan9 protocols have been used over
> > shared memory for resource access on virtualized systems for the past
> > 3 years. There are certainly ways it can be further optimized, but it
> > is not a restriction.
>
> I think what Carsten means is to have a mmap interface over 9p, not
> implementing 9p by means of shared memory, which is what I guess
> you are referring to.
>
> If you want to share memory areas between a guest and the host
> or another guest, you can't do that with the regular Tread/Twrite
> interface that 9p has on a file.
>
Well, there's nothing strictly preventing a mmap interface over 9p (in
fact we are working with that in a Cell project internally) --
however, I'm not sure that makes the best sense for device access
anyways. The real thing missing from the current implementation is a
better underlying transport which can pass payloads by reference to
shared memory as opposed to marshaling operations through a shared
memory transport -- however, this is what Los Alamos and IBM are
working on right now.
> > As far as complexity goes, our guest-side stack
> > is around 2000 lines of code (with an additional 1000 lines of support
> > routines that could likely be replaced by standard library or OS
> > services in more conventional platforms) and supports console, file
> > system, network, and block device access.
>
> Another interface that I think is missing in 9p is a notification
> for hotplugging. Of course you can have a long-running read on a
> special file that returns the file names for virtual devices that
> have been added or removed in the guest, but that sounds a little
> clumsy compared to an specialized interface (e.g. Tnotify).
>
Discovery and hot-plugging would be synthetic file system semantic
issues that need to be resolved and in general are probably, as Rusty
and others suggested, best handled as a separate set of topics. That
being said, specialized interfaces always seemed a bit more clunky to
me (just look at ioctl), but I suppose that's largely a matter of
taste. The advantage of having a file system interface to event
notification is it creates a much more flexible environment, allowing
even simple shell scripting languages to resolve events versus having
to build a complex infrastructure -- and since 9p can be transitively
mounted over a network, you can build cluster management suites
without secondary layers of gorp for such things. The LANL guys will
probably have more to say about this at their OLS talk on the KVM
management synthetic file system interface they build with 9p.
-eric
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
