bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [PATCH v2 4/4] Exclude TPM ioctls definitions for the GNU/Hurd
Date: Mon, 22 Jan 2024 17:16:22 +0000

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?
If the latter, then the simple thing would be to delete
this enum entirely, because as far as I can see we don't
use any of the values in QEMU, so we can avoid the
portability problem that way.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]