| Message ID | 20240311135230.7007-2-ilpo.jarvinen@linux.intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | selftests/resctrl: resctrl_val() related cleanups & improvements | expand |
Hi Ilpo, On 3/11/2024 6:52 AM, Ilpo Järvinen wrote: > The open() side handles fds in a for loop but close() is based on two > fixed indexes READ and WRITE. > > Match the close() side with the open() side by using for loop for > consistency. I find the close() side to be more appropriate. I say this for two reasons: (a) looking at the close() calls as they are now it is obvious what the close() applies to and transitioning to a loop adds a layer of unnecessary indirection, (b) I do not think a loop is appropriate for the READ/WRITE define that just happen to be 0 and 1 ... there should not be an assumption about their underlying value. Reinette
On Tue, 19 Mar 2024, Reinette Chatre wrote: > On 3/11/2024 6:52 AM, Ilpo Järvinen wrote: > > The open() side handles fds in a for loop but close() is based on two > > fixed indexes READ and WRITE. > > > > Match the close() side with the open() side by using for loop for > > consistency. > > I find the close() side to be more appropriate. I say this for two > reasons: (a) looking at the close() calls as they are now it is > obvious what the close() applies to and transitioning to a loop > adds a layer of unnecessary indirection, (b) I do not think a loop > is appropriate for the READ/WRITE define that just happen to be 0 > and 1 ... there should not be an assumption about their underlying > value. Hi, So to confirm are you suggesting I should remove all the other loops instead?
On Fri, 22 Mar 2024, Ilpo Järvinen wrote: > On Tue, 19 Mar 2024, Reinette Chatre wrote: > > On 3/11/2024 6:52 AM, Ilpo Järvinen wrote: > > > The open() side handles fds in a for loop but close() is based on two > > > fixed indexes READ and WRITE. > > > > > > Match the close() side with the open() side by using for loop for > > > consistency. > > > > I find the close() side to be more appropriate. I say this for two > > reasons: (a) looking at the close() calls as they are now it is > > obvious what the close() applies to and transitioning to a loop > > adds a layer of unnecessary indirection, (b) I do not think a loop > > is appropriate for the READ/WRITE define that just happen to be 0 > > and 1 ... there should not be an assumption about their underlying > > value. > > Hi, > > So to confirm are you suggesting I should remove all the other loops > instead? Nevermind, I read the comment to second patch, so the answer is yes. :-)
diff --git a/tools/testing/selftests/resctrl/resctrl_val.c b/tools/testing/selftests/resctrl/resctrl_val.c index 5a49f07a6c85..36139cba7be8 100644 --- a/tools/testing/selftests/resctrl/resctrl_val.c +++ b/tools/testing/selftests/resctrl/resctrl_val.c @@ -368,10 +368,9 @@ static int get_mem_bw_imc(int cpu_no, char *bw_report, float *bw_imc) writes += w->return_value.value * of_mul_write * SCALE; } - for (imc = 0; imc < imcs; imc++) { - close(imc_counters_config[imc][READ].fd); - close(imc_counters_config[imc][WRITE].fd); - } + for (imc = 0; imc < imcs; imc++) + for (j = 0; j < 2; j++) + close(imc_counters_config[imc][j].fd); if (strcmp(bw_report, "reads") == 0) { *bw_imc = reads;
The open() side handles fds in a for loop but close() is based on two fixed indexes READ and WRITE. Match the close() side with the open() side by using for loop for consistency. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> --- tools/testing/selftests/resctrl/resctrl_val.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)