Yea, no one said it would be easy ;-).  It's still the right thing to do
though.

For all the effort we put in to modularity elsewhere, we dropped the ball
when it came to config files... dating back to when we first moved
configuration into python, we underestimated the amount of reuse that would
be needed at that level, so we started off just slapping stuff together.
 It's evolved somewhat since then, but it could really use a ground-up
rearchitecting.

Steve

On Fri, Mar 2, 2012 at 2:03 PM, Gabriel Michael Black <[email protected]
> wrote:

> I think the problem underlying even that approach is that the code in
> configs/common isn't very amenable to being used by anything other than the
> code it was designed to work with. The first thing to do would be to
> refactor that code so it's more modular and reusable and doesn't have so
> many implicit dependencies.
>
> Gabe
>
> Quoting Steve Reinhardt <[email protected]>:
>
>  No, there is no common place.  This relates to a comment I made on a
>> different thread just a day or two ago, which is that we should
>> restructure
>> the regressions to use the code in configs/common so that there's only one
>> copy of most of this kind of code, and so that it gets tested by the
>> regressions.
>>
>> Of course, this situation also points to the need to actually run the
>> regressions using util/regress rather than just assuming the regressions
>> will pass based on a few ad-hoc tests.
>>
>> Steve
>>
>> On Fri, Mar 2, 2012 at 3:35 AM, Nilay Vaish <[email protected]> wrote:
>>
>>  I just realized that no script in tests/configs calls the function
>>> cache_config() in configs/common/CacheConfig.py, where the interrupt
>>> controller is being created. Similarly, since ruby_fs.py also does not
>>> call
>>> this function, it is also broken.
>>>
>>> Is there some common place where the createInterruptController function
>>> can be called?
>>>
>>> --
>>> Nilay
>>>
>>>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to