Hi On Tue, May 2, 2017 at 10:25 PM Patrick Ohly <patrick.o...@intel.com> wrote:
> On Tue, 2017-05-02 at 13:19 -0400, Stefan Berger wrote: > > On 05/02/2017 01:09 PM, Marc-André Lureau wrote: > > > On Tue, May 2, 2017 at 8:59 PM Stefan Berger < > stef...@linux.vnet.ibm.com> > > > wrote: > > > > > >> And who is going to implement that qemu-swtpm? Obviously this > discussion > > >> doesn't contribute to progress if nobody is doing that in the end. > > >> > > > The same persons who try to push for that emulated TPM code. The > easiest > > > approach would be to copy/adapt the swtpm code in qemu, if the licence > is > > > compatible. I can help with that if there is a consensus it's a better > > > approach. > > > > > > It's a matter of time and at least I don't have time for that. > > Neither do I, and nor (I believe) does Amarnath. The approach with using > the existing swtpm project seemed attractive to us exactly because it > avoids having to write and maintain more than just the glue code between > the two projects. > The main argument is not about having more or less code in qemu to maintain, but yes this is a concern (although giving up that maintenance to a seperate project with mostly Stefan-alone isn't a much better alternative). btw, is the project actually used by something else than qemu? (I am not talking about developpers/testing). If not, then it makes sense to make it part of qemu. But it's mostly a technical reason, to avoid having to rely on a foreign protocol and project with all the compatibility constrains. In the end, we may decide to start with a separate project, and change it in the future if it's problematic (that would break some cases, such as being able to freely switch the helper). Tbh, I am not so happy with the code quality of swtpm, and I haven't looked closely at libtpms. Having a qemu-swtpm as part of qemu would probably help improve it too, and bring a few more developers for maintainance... -- Marc-André Lureau
