Re: [PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd

[Stefan Berger]

On 1/22/24 15:46, Peter Maydell wrote:
> On Mon, 22 Jan 2024 at 19:30, Stefan Berger <stefanb@linux.ibm.com> wrote:
> > On 1/22/24 12:16, Peter Maydell wrote:
> > > On Thu, 18 Jan 2024 at 16:04, Manolo de Medici <manolodemedici@gmail.com> wrote:
> > > > The Hurd currently doesn't have any TPM driver, compilation fails
> > > > for missing symbols unless these are left undefined.
> > > >
> > > > Signed-off-by: Manolo de Medici <manolo.demedici@gmail.com>
> > > > ---
> > > >    backends/tpm/tpm_ioctl.h | 2 +-
> > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h
> > > > index 1933ab6855..c721bf8847 100644
> > > > --- a/backends/tpm/tpm_ioctl.h
> > > > +++ b/backends/tpm/tpm_ioctl.h
> > > > @@ -274,7 +274,7 @@ typedef struct ptm_lockstorage ptm_lockstorage;
> > > >    #define PTM_CAP_SEND_COMMAND_HEADER (1 << 15)
> > > >    #define PTM_CAP_LOCK_STORAGE       (1 << 16)
> > > >
> > > > -#ifndef _WIN32
> > > > +#if !defined(_WIN32) && !defined(__GNU__)
> > > >    enum {
> > > >        PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
> > > >        PTM_INIT               = _IOWR('P', 1, ptm_init),
> > > > --
> > > > 2.43.0
> > >
> > > This looks plausible as a change, but looking at the history
> > > of the file in git it seems like this is a file we import
> > > from a third-party swtpm project.
> > >
> > > Stefan: should we get this change made in the swtpm project
> > > too? Or have we diverged from that copy of the header?
> >
> > The diffs are minimal at the moment:
> > $ diff swtpm/include/swtpm/tpm_ioctl.h qemu/backends/tpm/tpm_ioctl.h
> > 15,16d14
> > < #include <stdint.h>
> > < #include <sys/types.h>
> >
> > Since we already handle _WIN32 we can just take this case for __GNU__.
>
> OK, so how should we handle the mechanics of it -- just take
> this commit in QEMU and then you'll sort it out in swtpm?

Yes.

> Or do we need to change swtpm first and then sync?

No.

Regarding the patch:

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>

> thanks
> -- PMM