On 09/02/2016 06:13 PM, Tamas K Lengyel wrote: > On Sep 2, 2016 09:03, "Jan Beulich" <jbeul...@suse.com > <mailto:jbeul...@suse.com>> wrote: >> >> >>> On 02.09.16 at 16:50, <ta...@tklengyel.com > <mailto:ta...@tklengyel.com>> wrote: >> > On Sep 2, 2016 05:45, "Jan Beulich" <jbeul...@suse.com > <mailto:jbeul...@suse.com>> wrote: >> >> >> >> >>> On 02.09.16 at 13:18, <rcojoc...@bitdefender.com > <mailto:rcojoc...@bitdefender.com>> wrote: >> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote: >> >> >>>>> On 02.09.16 at 10:51, <rcojoc...@bitdefender.com > <mailto:rcojoc...@bitdefender.com>> wrote: >> >> >>> Changes since V1 / RFC: >> >> >>> - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(), >> >> >>> and XENMEM_access_op_set_access_sparse to >> >> >>> XENMEM_access_op_set_access_multi. >> >> >>> - Renamed the 'nr' parameter to 'size'. >> >> >> >> >> >> Why? >> >> > >> >> > Tamas suggested it, size sounded more intuitive to him. I have no >> >> > problem with either nr or size. >> >> >> >> Size to me means something in bytes, which clearly isn't the case >> >> here. There's not even support for other then 4k pages so far. >> > >> > Lets make it array_size then to clarify? >> >> What's wrong with "nr", matching the other (existing) function? >> > > IMHO it's too generic. So either a more descriptive name or a comment is > warranted to explain the inputs.
If this satisfies everybody, I'll keep 'nr' and add a comment describing the function and parameters (which is a good thing anyway). Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
