----- Original Message -----
> On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote:
> >
> > This mail is meant to get a discussion started. Please keep me on
> > cc
> > for the discussion, as I'm not subscribed to libvir-list.
> >
> > ivshmem is an implementation of an inter-VM communication channel.
> > Support for this has been in qemu since v0.14.0 and libvirt patches
> > have been recently posted[1]. What's still missing is the ivshmem
> > server. The ivshmem server is needed when one would like to use
> > interrupts with ivshmem. The server manages a set of eventfds
> > to send/recv those interrupts. There is currently only one
> > implementation of this server that I'm aware of, which is available
> > from this git repo [2] in the ivshmem-server directory. My
> > suggestion
> > for libvirt is that this code be integrated into libvirt, rather
> > than managed by libvirt, for the following reasons
> >
> > 1. libvirt should keep track of the socket path in order to build
> > ivshmem's command line anyway.
> > 2. the current ivshmem server code is ~300 lines, so it shouldn't
> > be
> > a large integration effort.
> > 3. keeping ivhsmem server separate increases the package management
> > that distributions need to do. afaik, it isn't currently
> > packaged
> > for any distribution.
> >
> > One concern I have with the git repo [2] is that I don't see any
> > license for ivshmem-server. I've cc'ed Cam for his input.
>
> I guess my main question would be how much more, if any, is the
> ivshmem-server expected to grow over time ? I wouldn't want to
> get into a fork-situation if people are planning to do much more
> dev work on the current ivshmem-server code.
Here's the entire git log for ivshmem-server
Date: Thu Sep 6 11:36:33 2012 -0600
Error clean-up
Fixed a warning and cleaned up two error message
Date: Tue Nov 16 11:11:16 2010 -0700
just a few fixups
Date: Tue Jun 15 14:43:01 2010 -0600
Adding the ivshmem server here - Cam
So there was an initial drop, then nothing for two years, and then
some recent cleanups. I believe that it serves a simple enough
purpose that there shouldn't be any more growth.
>
> NB, if the code is integrated into libvirt, I think it would
> still have to run in a separate daemon. The reason is that we
> want to ensure that guests remain fully functional, even when
> libvirtd is stopped (whether for RPM upgrade, or due to crash)
>
> I've no particular strong opinion either way on your proposal.
> On the surface it seems reasonable to me.
>
> Daniel
> --
> |: http://berrange.com -o-
> | http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o-
> | http://virt-manager.org :|
> |: http://autobuild.org -o-
> | http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o-
> | http://live.gnome.org/gtk-vnc :|
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list