On 16.09.2019 12:59, Pawel Wieczorkiewicz wrote:
@@ -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. */
+ uint64_t name_total_size; /* OUT: Total size of all transfer names */
Why uint64_t and not uint32_t? You don't expect this to grow
beyond 4GiB, do you?
I don’t, but uint32_t is not really compatible with size_t.
And I was thought to always use size_t compatible types for sizes.
Anyway, I do not mind changing this to whatever type you prefer.
And why OUT rather than IN/OUT? Once you make this "arbitrary
size", I don't see a need for limiting this to ...
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_LIVEPATCH_NAME_SIZE bytes per entry.
Changing the upper bound limitation will break certain assumptions and I did not want to pile all these on top of the current change.
But, yes, the upper bound limit could be dropped. I would prefer to do it as an independent patch.
And finally - please send to the list just once, i.e. please
don't have two xen-devel@ in the recipients list.
Sorry, I did not notice the add_maintainers.pl script adds an explicit To: for the xen-devel@.
