On Tue, 18 Nov 2014, Steve Reinhardt via gem5-dev wrote:
I haven't looked at the code in question, so I'm just going by what I've seen in this email thread. However, it seems like there ought to be some alternative solutions here. I like the general direction Andreas is going, though it would be nice to avoid more multiple inheritance :). The way I see it, the basic idea there is to create an API (either on an existing object like System or on a new object) that the device can call irrespective of whether KVM is configured or not, but which gives enough information to get the job done; then the other object can be responsible for either coordinating with KVM or (presumably) ignoring all those calls if KVM is not configured. As a simpler alternative, maybe we don't need to give the kvm pointer to the device via python; if the System object has an accessor that would return the vm pointer, then the device could call that during initialization, and it would of course just return NULL if kvm is not configured
But would not this also cause the same problem that we cannot compile on systems that do not have kvm support? In Andreas' suggestion, we would be selectively compiling certain file(s) which should resolve the issue.
-- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
