Gerd Hoffmann wrote:
Ok, lets rip out the in-kernel ioapic code then. It can (and has
been) done in userspace.
The justification is performance although that's not really true anymore
post TPR optimization.
But FWIW, I opposed both the in-kernel apic and the in-kernel pit when
they were introduced. If nothing else, I'm at least consistent :-)
The daemon increases the possibility of userspace bugs.
How?
Seriously: Attaching a name tag to virtio-serial devices and have
them exposed via sysfs is probably *much* less code than a vmchannel
daemon.
I strongly doubt that.
If we really want
vmchannel to be used by application developers, then we really need a
libvmchannel.
We need a sane solution developed and merged and not a new idea each
week.
There is nothing sane about vmchannel. It's just an attempt to bypass
QEMU which is going to introduce all sorts of complexities wrt
migration, guest compatibility, etc.
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with virtio-console.
If the two are converged, I'm happy to merge it. I'm not opposed to
having more functionality.
I think it's the wrong solution for the use-case, and I always have, but
that's independent of my willingness to merge it.
Regards,
Anthony Liguori
--
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
