On Sep 2, 2016 09:17, "Razvan Cojocaru" <rcojoc...@bitdefender.com> wrote: > > 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). > >
SGTM. Thanks, Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
