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
