Re: [kvm-unit-tests PATCH] lib/s390x/sclp: Clarify that the CPUEntry array could be at a different spot

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

 



On 21.01.21 07:57, Thomas Huth wrote:
> The "struct CPUEntry entries[0]" in the ReadInfo structure is misleading
> since the entries could be add a completely different spot. Replace it
> by a proper comment instead.
> 
> Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx>
> ---
>  lib/s390x/sclp.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/s390x/sclp.h b/lib/s390x/sclp.h
> index 9f81c0f..8523133 100644
> --- a/lib/s390x/sclp.h
> +++ b/lib/s390x/sclp.h
> @@ -131,10 +131,15 @@ typedef struct ReadInfo {
>  	uint16_t highest_cpu;
>  	uint8_t  _reserved5[124 - 122];     /* 122-123 */
>  	uint32_t hmfai;
> -	uint8_t reserved7[134 - 128];
> +	uint8_t reserved7[134 - 128];       /* 128-133 */
>  	uint8_t byte_134_diag318 : 1;
>  	uint8_t : 7;
> -	struct CPUEntry entries[0];
> +	/*
> +	 * At the end of the ReadInfo, there are also the CPU entries (see
> +	 * struct CPUEntry). When the Extended-Length SCCB (ELS) feature is
> +	 * enabled, the start of the CPU entries array begins at an offset
> +	 * denoted by the offset_cpu field, otherwise it's at offset 128.
> +	 */
>  } __attribute__((packed)) ReadInfo;
>  
>  typedef struct ReadCpuInfo {
> 

Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>

-- 
Thanks,

David / dhildenb




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux