It took me a second to appreciate what the goal of separating this is, but it makes complete sense to me now. This was an oversight on my end as well when I was working on the config changes in once of the patches I was assigned. Interestingly enough, I ran into a similar problem with circular dependencies a long time ago when I was attempting to do some 'arch' discovery changes, which I still intend to implement. I think putting the node config in the os_session component makes sense from a readability standpoint as well.
On Mon, Oct 28, 2024 at 1:51 PM Luca Vizzarro <luca.vizza...@arm.com> wrote: > > The DPDKBuildInfo and NodeInfo classes, representing information > gathered in runtime, were erroneously placed in the configuration > package. This moves them in more appropriate modules. > > NodeInfo, specifically, ia moved to os_session instead of node mostly Small typo here, change 'ia' to 'is'. > as a consequence of circular dependencies. And given os_session is the > top-most module to reference it, it appears to be the most suitable > place outside of node. As I said, this makes sense to me, but I wonder if it might make sense to change 'NodeInfo' to 'OSSessionInfo' or something like that. I'd imagine that if any attributes were to be tacked on in the future they would probably be os related, but maybe there would be system information, and in this case "OSSessionInfo" might be a good middle ground. There are existing changes that I've done where arch is discovered during runtime, and this could probably be placed in this 'NodeInfo' class as well when I get around to revising it. My only concern is whether or not having "NodeConfiguration" and "NodeInfo" classes floating around might make the framework more confusing to read. <snip>
