Replies below: -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Nilay Vaish Sent: Thursday, April 30, 2015 8:20 AM To: gem5 Developer List Subject: Re: [gem5-dev] Review Request 2749: cpu: testers: rubytest: fix the test
On Wed, 29 Apr 2015, Beckmann, Brad wrote: > My main objection to the change is that it is not worth the time. It > is taking a sledgehammer to a bug that only requires a minor tweak. > There is a lot of downstream code that will be impacted by a change > that doesn't provide any real benefit. To do what you want the right > way, would require making the CheckTable and RubyTesters separate > SimObjects and then instantiating them appropriately. Why go through > all that trouble? I am willing to go through all the trouble because I am confident that the right way is to have multiple testers and not one single tester. Anyways, there are two questions that come to my mind here. First, let's for an instant assume that we do not want to change ruby tester's c++ code. How do you propose we fix the current bug? Since you have not posted any code, I am discussing what I think would be done. We will have to make each protocol configuration file understand that it cannot assume that the number of cpu objects is same as options.num_cpus and do something different when the two quantities are unequal. Do we want to put that down as a policy? Don't you think this renders the option meaningless? [BB] This is where I don't fully understand the bug you are encountering. The number of cpus is different than the number of testers. The number of cpus should impact the number of m5 ports provided by the tester, not the number of testers. That is how the tester has worked in the past. If the current configurations don't support that, then they need to be fixed. Second, this question is more general and should be discussed more widely. When is a change deemed as 'impacting downstream code'? And what should be our policy for such changes? [BB] When new features are added to the code, then one should expect that downstream code should be impacted. However, a simple problem in configuration should not require one to change how ruby testers are architected. More ruby testers exist than what is currently available in the public tree. > What separate code are you concerned about? The specific code to handle > the tester in Ruby (C++) has nothing to do with whether there is one > RubyTester or multiple RubyTesters. > May be it has nothing to do with single or multiple testers. But you agree that we have code where we behave differently if a tester is running. And I do not want such code to proliferate. [BB] I think the fundamental problem there is the too simplistic RubyPort interface. There are several problems that could be fixed if we allowed a richer set of information to be passed between Ruby and the packet generators (CPUs/testers/GPUs/etc.). -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
