On Wed, Mar 01, 2017 at 12:25:46PM -0500, Stefan Berger wrote: > On 03/01/2017 12:16 PM, Michael S. Tsirkin wrote: > > On Wed, Mar 01, 2017 at 12:12:34PM -0500, Stefan Berger wrote: > > > On 03/01/2017 12:02 PM, Michael S. Tsirkin wrote: > > > > 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. > > > Who should define it? > > > > > No one. Put it in same source tree with QEMU and forget ABI stability > > issues. > > You mean put the code implementing TPM 1.2 and/or TPM 2 into the QEMU tree? > These are multiple thousands of lines of code each and we'll break them > apart into logical chunks and review them?
No, lets not make that mistake again - we only just got rid of the libcacard smartcard library code from QEMU git. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
