Re: [Xen-devel] [PATCH v3 13/23] XENVER_build_id: Provide ld-embedded build-ids (v10)

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/02/16 20:22, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 16, 2016 at 08:09:13PM +0000, Andrew Cooper wrote:
>> On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
>>
>> Building the hypervisor with buildid and making it available via
>> hypercall really should be split into two different patches, especially
>> given the complexity in each.
> OK, will do.
>
>
> .. snip..
>
>>> +/* Return value is the number of bytes written, or XEN_Exx on error.
>>> + * Calling with empty parameter returns the size of build_id. */
>>> +#define XENVER_build_id 10
>>> +struct xen_build_id {
>>> +        uint32_t        len; /* IN: size of buf[]. */
>>> +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>>> +        unsigned char   buf[];
>>> +#elif defined(__GNUC__)
>>> +        unsigned char   buf[1]; /* OUT: Variable length buffer with 
>>> build_id. */
>>> +#endif
>>> +};
>>> +typedef struct xen_build_id xen_build_id_t;
>> I am still against trying to perpetuate this broken interface.  Variable
>> length structures are a pain for everyone to use.  How about introducing
>> a brand new hypercall with a separate length and data parameters?
> As in subop to sysctl? I am fine with that (which is what I think was
> in the first iteration of this patch had). Or it could go under the
> XSPLICE subops :-)
>
> Preferences?

A completely brand new hypercall.  Then we can deprecate the existing
xenver, including moving the relevent information such as plain version
numbers and leaving the irrelevant information (compile date, etc.).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel