> -----Original Message----- > From: Andrew Cooper > Sent: 10 April 2017 10:29 > To: Paul Durrant <paul.durr...@citrix.com>; Xen-devel <xen- > de...@lists.xen.org> > Cc: Jennifer Herbert <jennifer.herb...@citrix.com>; Jan Beulich > <jbeul...@suse.com>; Julien Grall <julien.gr...@arm.com> > Subject: Re: [PATCH v5 for-4.9 1/4] hvm/dmop: Box dmop_bufs rather than > passing two parameters around > > On 10/04/17 10:04, Paul Durrant wrote: > >> -----Original Message----- > >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> Sent: 07 April 2017 20:36 > >> To: Xen-devel <xen-devel@lists.xen.org> > >> Cc: Jennifer Herbert <jennifer.herb...@citrix.com>; Andrew Cooper > >> <andrew.coop...@citrix.com>; Jan Beulich <jbeul...@suse.com>; Paul > >> Durrant <paul.durr...@citrix.com>; Julien Grall <julien.gr...@arm.com> > >> Subject: [PATCH v5 for-4.9 1/4] hvm/dmop: Box dmop_bufs rather than > >> passing two parameters around > >> > >> From: Jennifer Herbert <jennifer.herb...@citrix.com> > >> > >> No functional change. > >> > > Why is this a good thing? Passing two parameters around allowed for them > to be in registers. I preferred the code as it was before. > > a) It will always be inlined, so registers aren't relevant.
Why? I see nothing forcing the compiler to make it so. > Even if > they were, all values are available directly with the pointer as a base, > so there is no reduction in expressiveness. (i.e. the previous code > only increases register pressure). > b) passing multiple parameters like that is a recipe for mistakes, and > in this case, mistakes mean security vulnerabilities. Given the locality of the code I don't buy that as an argument unless you're going to assert that passing more than one parameter is always wrong. > c) It is necessary to make legible code for the later changes in this > series. > From my reading I don't think it would have an overly negative effect on the subsequent patches if this patch were dropped. Paul > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel