On Wed, Mar 01, 2017 at 04:31:04PM +0000, Daniel P. Berrange wrote:
On Wed, Mar 01, 2017 at 06:22:45PM +0200, Michael S. Tsirkin wrote:
On Wed, Mar 01, 2017 at 09:50:38AM -0500, Stefan Berger wrote:
I had already proposed a linked-in version before I went to the out-of-process
design. Anthony's concerns back then were related to the code not being trusted
and a segfault in the code could bring down all of QEMU. That we have test
suites running over it didn't work as an argument. Some of the test suite are
private, though.
Given how bad the alternative is maybe we should go back to that one.
Same argument can be made for any device and we aren't making
them out of process right now.
IIMO it's less the in-process question (modularization
of QEMU has been on the agenda since years and I don't
think anyone is against it) it's more a code control/community question.
I rather disagree. Modularization of QEMU has seen few results
because it is generally a hard problem to solve when you have a
complex pre-existing codebase. I don't think code control has
been a factor in this - as long as QEMU can clearly define its
ABI/API between core & the modular pieces, it doesn't matter
who owns the module. We've seen this with vhost-user which is
essentially outsourcing network device backend impls to a 3rd
party project.
And it was done precisely for community reasons. dpdk/VPP community is
quite large and fell funded but they just can't all grok QEMU. They
work for hardware vendors and do baremetal things. With the split we
can focus on virtualization and they can focus on moving packets around.
QEMU's defined the vhost-user ABI/API and delegated
impl to something else.
The vhost ABI isn't easy to maintain at all though. So I would not
commit to that lightly without a good reason.
It will be way more painful if the ABI is dictated by a 3rd party
library.