From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v8 05/13] x86: expose CBM length and COS number information Date: Fri, 29 May 2015 10:29:45 +0100 Message-ID: <55684DA9020000780007EE68@mail.emea.novell.com> References: <1432197704-20816-1-git-send-email-chao.p.peng@linux.intel.com> <1432197704-20816-6-git-send-email-chao.p.peng@linux.intel.com> <5567338B020000780007E9AE@mail.emea.novell.com> <20150529024713.GD18422@pengc-linux.bj.intel.com> <55683A66020000780007ED50@mail.emea.novell.com> <1432891393.5077.5.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1432891393.5077.5.camel@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, will.auld@intel.com, Chao Peng , dgdegra@tycho.nsa.gov, keir@xen.org List-Id: xen-devel@lists.xenproject.org >>> On 29.05.15 at 11:23, wrote: > On Fri, 2015-05-29 at 09:07 +0100, Jan Beulich wrote: >> >>> On 29.05.15 at 04:47, wrote: >> > On Thu, May 28, 2015 at 02:26:03PM +0100, Jan Beulich wrote: >> >> >> >> > --- a/xen/include/public/sysctl.h >> >> > +++ b/xen/include/public/sysctl.h >> >> > @@ -694,6 +694,20 @@ struct xen_sysctl_pcitopoinfo { >> >> > typedef struct xen_sysctl_pcitopoinfo xen_sysctl_pcitopoinfo_t; >> >> > DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t); >> >> > >> >> > +#define XEN_SYSCTL_PSR_CAT_get_l3_info 0 >> >> > +struct xen_sysctl_psr_cat_op { >> >> > + uint32_t cmd; /* IN: XEN_SYSCTL_PSR_CAT_* */ >> >> > + uint32_t target; /* IN: socket to be operated on */ >> >> >> >> If this is always the socket number, why would the variable be >> >> named anything other than "socket". If otoh subsequent patches >> >> use it differently, I think the comment should be omitted now >> >> rather than being dropped then (or it should be given its final >> >> wording from the beginning). >> > >> > Or 'target to be operated on'? >> >> Fine with me. Just not something that may end up being confusing. >> > So, I really don't want to turn this into pure bikeshedding, but, for a > field called 'target', a comment saying 'target to be operated on' seems > rather pointless, and I'd go for omitting it (for now). Right - my earlier response was merely meant to say I'm not opposed to a non-confusing comment, not that I see a strict need for a mostly redundant one here. Jan