Hi Tony, On 2/9/2024 1:36 PM, Luck, Tony wrote: >>> Reinette seem to have some concerns about this series. But, I am fine with >>> both these approaches. I feel this is more clean approach. >> >> I questioned the motivation but never received a response. > > Reinette, > > Sorry. My motivation was to reduce the amount of code churn that > was done in the by the previous incarnation. > > 9 files changed, 629 insertions(+), 282 deletions(-) > > Vast amounts of that just added "_mon" or "_ctrl" to structure > or variable names. I actually had specific points that this response also ignores. Let me repeat and highlight the same points: 1) You claim that this series "removes the need for separate domain lists" ... but then this series does just that (create a separate domain list), but in an obfuscated way (duplicate the resource to have the monitoring domain list in there). 2) You claim this series "reduces amount of code churn", but this is because this series keeps using the same original data structures for separate monitoring and control usages. The previous series made an effort to separate the structures for the different usages but this series does not. What makes it ok in this series to use the same data structures for different usages? Additionally: Regarding "Vast amounts of that just added "_mon" or "_ctrl" to structure or variable names." ... that is because the structures are actually split, no? It is not just renaming for unnecessary churn. What is the benefit of keeping the data structures to be shared between monitor and control usages? If there is a benefit to keeping these data structures, why not just address this aspect in previous solution? Reinette
