Quoting Steve Reinhardt <[email protected]>:
On Fri, Sep 30, 2011 at 9:18 PM, Gabriel Michael Black <
[email protected]> wrote:
One thing I don't agree with is that they should be associated with the
system object. It doesn't need to know how the PCI space is allocated or be
able to send interrupts to the CPU through the chipset's IO controller.
It's true that the System object itself may not need to know these things,
but we get a lot of simplicity out of having per-system objects associated
with System, because then each device or whatever that does need to know
about these per-system components can find them as long as they have a
System pointer. I think in this situation it plays a role closer to a
namespace than anything else.
There were no uses for that in the code, except for the one I
eliminated which wasn't necessary. Using the System object as a
collection point for hardware also makes enforces about that hardware,
for instance that there's only one interrupt controller. We shouldn't
build assumptions like that in at a fundamental level, we should have
higher level (and optional) python constructs that hook up the
primitives correctly, like the code code in FSConfig.py does more or
less. In the mean time, by having that parameter we've actually added
an additional component/setting/connection that wouldn't have been
there otherwise, reducing simplicity.
Devices do, but moving radially outwards from the CPU they are (for the
most part) beyond the system object.
Hmm? I think the System object logically encompasses everything that's part
of the system, including devices... if not directly as parameters, then as
the root of the configuration subtree. The only things that aren't under a
System object are things that connect systems (right now the Etherlink is
the only thing in that category).
I always thought of the System object as the OS and the software side
of things. I think it serves a valuable purpose there, but not really
any purpose for the devices. In my mind the hardware part was always
the Platform object which we're getting rid of. It all gets pretty
murky, though, and I've never been sure exactly what is for what. As I
mentioned, there was a single use of the platform pointer from
something that wasn't a device. It's apparently just not useful. If it
isn't useful and it decreases modularity by adding a dependence on
there being a Platform object or the objects it replaces, I don't see
any reason to keep it.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
