Hi Tony, On 9/26/2023 3:14 PM, Luck, Tony wrote: >>> But this seems like it is a lot of churn to avoid having separate >>> functions to search control and monitor lists. Each a clone of >>> the existing ~24 line rdt_find_domain() with just the type changed >>> for the return value and the list travsersal. >> >> Yes. Sorry, I did not realize this implication during the earlier >> discussions. >> >>> >>> What do you think? >>> >> >> It sounds to me as though you are advocating for open coding >> rdt_find_ctrl_domain() and rdt_find_mon_domain()? That sounds good >> to me. > > Reinette, > > While there is some churn, it maybe isn't all that bad. I also ran the open > coding case and having a pair of 24-line functions one after the other with > just two trivial lines changed between them is unlikely to get past the x86 > maintainers without running this same conversation again. > I expect you are right and your proposal makes the code cleaner. Could the list_entry() call within rdt_find_domain() instead extract a pointer to a struct rdt_domain_hdr? To me that would make it most generic and avoid using wrong type for a pointer. I do think that may have been what you intended by moving id in there though ... Reinette