Hi On Wed, Mar 1, 2017 at 10:20 PM Michael S. Tsirkin <m...@redhat.com> wrote:
> > > You're also tieing the code > > into the QEMU release cycle, again for no tangible benefit. > > No need for ABI stability would be the benefit. > We are talking about the control channel ABI (the data channel is using TCG defined command streams afaict - don't remember what it is called) > > > Conceptually > > swtpm does not depend on, or require, QEMU to be useful - it can have > > other non-QEMU consumers - bundling with QEMU is not helpful there. > > Maybe it could but it isn't. > Right, it would be reasonable to have qemu provide it's own private "swtpm" (linking with libtpms, doing most of the job), that way it wouldn't have to rely on a stable ABI (as long as the process isn't shared across different qemu versions, which should be quite easy to achieve) > > > > > > I don't know what are the other options. How is depending on an ABI > > > with a utility with no other users and not packaged by most distros > > > good? You are calling out to a CUSE device but who's reviewing that > > > code? > > > > If anyone is motivated enough to review the code, they can do it whether > > it is in QEMU git or its own git. Pulling entire of swtpm into QEMU GIT > > isn't magically going to get useful reviews done on the code. The QEMU > > maintainers already have far more code to review than available review > > bandwidth, and lack domain knowledge in TPM concepts. > > I was the only one merging TPM code so far. I don't call myself an > expert. If someone steps up to do the work, is trusted by Peter to > maintain it for X years and doesn't care about the extra hurdles, more > power to them. > Why not give Stefan maintainership of TPM? > > > > Anyway, it all boils down to lack of reviewers. I know I am not merging > > > the current implementation because I could not figure out what do qemu > > > bits do without looking at the implementation. I don't want to jump > > > between so many trees and coding styles. bios/qemu/linux/dpdk are > > > painful enough to manage. If some other maintainer volunteers, or if > > > Peter wants to merge it directly from Stefan, I won't object. > > > ok > > > > 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/ :| > -- Marc-André Lureau
