Markus,
see inline (I am not on all mailing list, please, keep the cc list).
> Sure! The reasons for my dislike range from practical to
> philosophical.
My practical concerns include:
1. ivshmem code needs work, but has no maintainer
See David's contributions:
http://patchwork.ozlabs.org/patch/358750/
2. There is no libvirt support
One can use qemu without libvivrt.
3. Out-of-tree server program required for full functionality
We have the source code, it provides the documentation to write our own
better server program.
4. Out-of-tree kernel uio driver required
No, it is optional.
These concerns are all fixable, but it'll take serious work, and time.
Something like:
* Find a maintainer for the device model
I guess, we can find it into the DPDK.org community.
* Review and fix its code
* Get the required kernel module upstream
which module? uio, it is not required.
* Get all the required parts outside QEMU packaged in major distros, or
absorbed into QEMU
Redhat did disable it. why? it is there in QEMU.
In short, create a viable community around ivshmem, either within the
QEMU community, or separately but cooperating.
At least, DPDK.org community is a community using it.
On to the more philosophical ones.
5. Out-of-tree interface required
Paraphrasing an old quip: Some people, when confronted with a
problem, think "I know, I'll use shared memory." Now they have two
problems.
Shared memory is not an interface. It's at best something you can
use to build an interface.
I'd rather have us offer something with a little bit more structure.
Very fast guest-to-guest networking perhaps.
It is not just networking, you have other use cases like HPC, sharing
in-memory databases.
6. Device models belong into QEMU
Say you build an actual interface on top of ivshmem. Then ivshmem in
QEMU together with the supporting host code outside QEMU (see 3.) and
the lower layer of the code using it in guests (kernel + user space)
provide something that to me very much looks like a device model.
Device models belong into QEMU. It's what QEMU does.
See my previous statement, it is not just device model.
Best regards,
Vincent
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
