On 17. Sep 2019, at 10:27, Jan Beulich
<jbeul...@suse.com<mailto:jbeul...@suse.com>> wrote:
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@.
Jan
Best Regards,
Pawel Wieczorkiewicz
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
