[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 10/12] livepatch: Handle arbitrary size names with the list operation
On 28.09.2019 17:13, Pawel Wieczorkiewicz wrote: > --- a/xen/include/public/sysctl.h > +++ b/xen/include/public/sysctl.h > @@ -925,10 +925,11 @@ struct xen_sysctl_livepatch_get { > * > * If the hypercall returns an positive number, it is the number (up to `nr`) > * of the payloads returned, along with `nr` updated with the number of > remaining > - * payloads, `version` updated (it may be the same across hypercalls. If it > - * varies the data is stale and further calls could fail). The `status`, > - * `name`, and `len`' are updated at their designed index value (`idx`) with > - * the returned value of data. > + * payloads, `version` updated (it may be the same across hypercalls. If it > varies > + * the data is stale and further calls could fail) and the name_total_size > + * containing total size of transferred data for the array. > + * The `status`, `name`, `len` are updated at their designed index value > (`idx`) > + * with the returned value of data. > * > * If the hypercall returns E2BIG the `nr` is too big and should be > * lowered. The upper limit of `nr` is left to the implemention. > @@ -951,11 +952,13 @@ struct xen_sysctl_livepatch_list { > amount of payloads and > version. > OUT: How many payloads left. > */ > uint32_t pad; /* IN: Must be zero. */ > + uint32_t name_total_size; /* OUT: Total size of all > transfer names */ > XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status; /* OUT. Must have > enough > space allocate for nr of > them. */ > XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each > member > - MUST XEN_LIVEPATCH_NAME_SIZE > in size. > - Must have nr of them. */ > + may have an arbitrary length > up to > + XEN_LIVEPATCH_NAME_SIZE > bytes. Must have > + nr of them. */ > XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of > name's. > Must have nr of them. */ > }; Non-binary-compatible changes require an interface version bump. I wonder though why you don't use the "pad" field; in fact the way you make the change you'd have to introduce a 2nd padding field, to make padding explicit _and_ check it's zero on input (for future extensibility _without_ having to bump the interface version). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |