Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM

[Marc-André Lureau]

Hi

On Wed, Mar 1, 2017 at 10:20 PM Michael S. Tsirkin <address@hidden> 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