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?
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?
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.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
