On Fri, Sep 23, 2022 at 09:15:07AM +0100, Bruce Richardson wrote: > On Fri, Sep 23, 2022 at 07:22:26AM +0000, Juraj Linkeš wrote: <snip> > > > > Absolutely, but effective time use is also something to consider. Our > > current plan doesn't won't really have to contend with problems in the > > future, as we want to add the Farbic implementation in the next release > > cycle. I'm also working on refactoring the code a bit - I'm adding an > > abstraction that would allow us to easily replace the pexpect > > implementation with Fabric (with no impact on DTS behavior - the same APIs > > will need to be implemented). Also, we'll remove the pexpect implementation > > once Fabric is in place (unless we can think of a reason for pexpect to > > stay, in which case we'll need to refactor it). I think that instead of > > focusing on pexpect we could focus on making sure the replacement won't > > cause any issues. What do you think? > > > > Personally, I would be very keen to get the move of DTS to the main repo > underway, and so I wouldn't look to have too many massive changes required > before we start seeing patches merged in. Basic code cleanup and > refactoring is fine, but I would think that requiring massive changes like > replacing expect with fabric may be too big an ask. After all, the rest of > DPDK is moving on, meaning more and more DTS content is being added to the > separate DTS repo every release, making the job bigger each time. :-( > > Tl;dr - I'm ok to leave fabric replacement for a release next year. > > /Bruce That makes sense. I would suggest however to put comments around implementation hacks and the public APIs simply to not forget.
Though I'd do the refactoring sooner than later because once tests start being merged there will be a higher possibility of them relying on hacks. -- Best Regards, Stanislaw Kardach
