> >>> +/* 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.).
How would you deprecate the xenver when there are existing guests that
depend on this? Say RHEL5, SLES11 or NetBSD? They are not going to move
over and it would be a bit of silly to deprecate something and actually
never deprecate it because of users still depending on it.
Let me stress out that I have no problems adding a new hypercall (albeit
I think it is an overkill), and adding BUILD_ID in it. However I wouldn't
have the time for Xen 4.7 to add the rest of the sub-ops in it - such as
version, command line, what not.
Keep in mind we have one month left..
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
