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. QEMU's defined the vhost-user ABI/API and delegated impl to something else. With the vTPM stuff here, we've not got a pre-existing feature we need to deal with, so the biggest blocker wrt modularization does not exist. Given that I think having the vTPM impl modularized is highly desirable, as long as we can define a sane ABI/API between QEMU and the external piece. So I think anthony's point about not putting a vTPM impl in-process is still valid, and since Stefan's already done much of the work to achieve a modular design we should not go back to an in-process design now. > It doesn't look like userspace swtpm bits have a large community of > developers around it, and the only user appears to be QEMU, so depending > on that externally does not make sense, we should just have them > in-tree. This way we don't need to worry about versioning etc. 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/ :|
