Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 24 Apr 2023 18:05:50 +0300 (EEST)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     Reinette Chatre <reinette.chatre@intel.com>
cc:     linux-kselftest@vger.kernel.org, Fenghua Yu <fenghua.yu@intel.com>,
        Shuah Khan <shuah@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Subject: Re: [PATCH v2 05/24] selftests/resctrl: Make span unsigned long
 everywhere
In-Reply-To: <83a61c92-01bf-0ac3-709d-7ba2ed0259b2@intel.com>
Message-ID: <6585df2-6b55-b1da-483-7c2e3356e6bf@linux.intel.com>
References: <20230418114506.46788-1-ilpo.jarvinen@linux.intel.com> <20230418114506.46788-6-ilpo.jarvinen@linux.intel.com> <83a61c92-01bf-0ac3-709d-7ba2ed0259b2@intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-702082943-1682348754=:2038"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-702082943-1682348754=:2038
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 21 Apr 2023, Reinette Chatre wrote:
> On 4/18/2023 4:44 AM, Ilpo Järvinen wrote:
> > fill_buf(), show_bw_info(), and resctrl_val_param.span define span as
> > unsigned long.
> 
> There is no fill_buf() in the code and show_bw_info() does
> not define span as unsigned long (it is even the first function
> changed in this patch).

Shuffling a large number of patches around seems detrimental for the 
quality of the commit messages no matter how hard I try to maintain them 
up to date. Thanks for noticing this.

> > Consistently use unsigned long elsewhere too for span parameters.
> 
> Is unsigned long the right type to use? Tracing through all the
> indirections I do not see how making all usages unsigned long
> achieves consistency ... have you considered size_t?

I'll change to size_t as it refers to the size of the memory block.

-- 
 i.

--8323329-702082943-1682348754=:2038--