[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <820cd2b6-b71b-435b-bc67-c35318f869e2@intel.com>
Date: Tue, 28 Oct 2025 10:40:44 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: Fenghua Yu <fenghuay@...dia.com>, Maciej Wieczor-Retman
<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>, Chen Yu
<yu.c.chen@...el.com>, <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
<patches@...ts.linux.dev>
Subject: Re: [PATCH v12 20/31] fs/resctrl: Refactor mkdir_mondata_subdir()
Hi Tony,
On 10/28/25 10:14 AM, Luck, Tony wrote:
> On Tue, Oct 28, 2025 at 09:00:46AM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 10/27/25 4:00 PM, Luck, Tony wrote:
>>> On Thu, Oct 23, 2025 at 10:45:06AM -0700, Reinette Chatre wrote:
>>>>> + sprintf(name, "mon_sub_%s_%02d", r->name, hdr->id);
>>>>> + ckn = kernfs_create_dir(kn, name, parent_kn->mode, prgrp);
>>>>
>>>> Noting here that kn was created earlier with mode of parent_kn->mode. It thus looks to me like
>>>> above can also be written as:
>>>> ckn = kernfs_create_dir(kn, name, kn->mode, prgrp);
>>>>
>>>> The reason I mention this is that this patch adds a third copy of a very similar code snippet
>>>> (kernfs_create_dir(), rdtgroup_kn_set_ugid(), mon_add_all_files()) that looks like a good
>>>> candidate for a helper?
>>>
>>> I looked at this. But the helper needs a lot of arguments to cover these
>>> three cases. Something like:
>>>
>>> static struct kernfs_node *make_and_fill_mondir(struct kernfs_node *parent_kn,
>>> char *name, umode_t mode,
>>
>> I aimed to preempt a response like this in the text you quoted that notes that
>> a "mode" argument does not seem necessary. Are you hinting that mode is indeed
>> required? If not, without "mode" there are six arguments which is just one more
>> than mon_add_all_files() that will be called by it.
>> What is the threshold for there being too many arguments? This series does not seem
>> to have trouble pushing an arch API call resctrl_arch_rmid_read() to eight arguments
>> while there is a concern with the number of arguments of this static call that has
>> fewer?
>
> Ok. you have me convinced. Since this helper will be the only caller
> of mon_add_all_files(), would it be good to just add the extra args
> needed to this function and have it create the directory and add the
> files? It would need a new name to describe the added functions it
> performs. Maybe mon_add_domain_dir()? But better suggestions welcomed.
Modifying mon_add_all_files() sounds good. I assume the node activation (kernfs_active())
will still be done by the caller which would have this new function return a struct kernfs_node *?
If so, I think it will make code easier to read if name implies that a new kn is created.
Since the caller is already mkdir_mondata_subdir(), what do you think of _mkdir_mondata_subdir()?
Reinette
Powered by blists - more mailing lists