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. Devices do, but moving radially outwards from
the CPU they are (for the most part) beyond the system object. For the
few cases where they aren't (the CPU's interrupt management object in
x86 for instance, maybe the table walker) they still don't need to
register themselves as PCI devices or send interrupts. And if we find
an even more unusual case where they really do, they can just refer to
those resources directly like the other devices.
But since adding a parameter that tells the System object where those
objects are is easy to do whenever, I'll just leave that part out for
now and get rolling.
Gabe
Quoting Steve Reinhardt <[email protected]>:
Yea, that was going to be the gist of my main comment on your original
email, once I got around to writing it... let's figure out where we want to
go in the long run (seems like we already agreed about getting rid of
Platform and having separate interrupt and PCI controller objects associated
independently with System), and head that direction. If it's too much to
bite off all at once, then we (or you) can identify some intermediate
step(s), but there's no point in defining the intermediate step first before
we know where we're headed and know that we can't make it there in one shot.
Steve
On Fri, Sep 30, 2011 at 6:30 PM, Gabe Black <[email protected]> wrote:
This might be a good opportunity to split the platform object into PCI
controller and interrupt controller objects. I'm thinking for
interrupts, I can create an IntDev which mirrors x86's but works with
the legacy Platform setup.
On 09/30/11 02:13, Gabe Black wrote:
> If anybody is following the work I'm doing to integrate SE and FS, I'm
> going to start doing that in a new gem5.sefs repository which you can
> access in the same way as the main repository. I'll periodically merge
> things into it from the main tree, and occasionally merge back over. The
> idea is to minimize disruption to what people are trying to use day to
> day, but also so that we can actually get through this involved
> transition in a timeframe that's at all reasonable. You can still see
> what's going on, though, and there will be discussion about how I'm
> doing things on the list. The emails that get these rolling will tend to
> be shorter and just introduce the issue instead of getting into the meat
> of it like I have in the past.
>
>
> So, right now there's a platform pointer for all devices, and, because
> it sends and receives interrupts over the memory system, the x86
> interrupt controller is a device. Having a platform object is not useful
> for the CPU side x86 interrupt controller, and also not useful for a
> number of other devices. I think it should the property should either be
> added individually where needed (for interrupt generating and PCI
> devices currently, I think) or put into an appropriate subclass which
> fits into the device class hierarchy somewhere. Preferences? If option
> two, where would the subclass go?
>
> Gabe
> _______________________________________________
> 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
_______________________________________________
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
