I'm working on making the various interrupt controllers talk to each
other, and I'm expecting to run into a tricky situation with multiple
inheritance. First, my patch queue is on daystrom as x86-patches if you
want to look at what I'm talking about directly. There are quite a few
patches which do a lot, but you'd mostly be interested in the later ones
having apic in their names.
Anyway, to make the PICs and APICs and interrupt sources connect to
each other nicely, I created a class called IntDev and a class called
IntPin. IntDev is intended to be a base for anything that can accept
interrupts, and IntPin is a small class exposed through python that
refers to an IntDev and has a pin number. The python version of IntDevs
have a function called pin(line) which returns an IntPin associated with
the device and recording the correct pin. When this gets to the C++ side
of things, a device triggers its interrupt by calling a function on the
IntPin which calls a function on the IntDev and passes it the
appropriate line. This makes things much cleaner in general, and I'm
pretty happy with it.
Then I started working on the APICs and getting them to talk to each
other, and I realize the PioPort doesn't let you -send- anything, just
receive. That's what it's supposed to do, and I don't think it would be
appropriate to try to change that, although I considered suggesting
that. I thought about it more, and it occurred to me that both APICs
have both pio aspects and interrupt message aspects which could be
represented separately. The IO APIC needs to be a PioDevice because it
does the same index/window trick the CMOS and PCI configuration space
use, and the Local APIC can be a BasicPioDevice. On top of that, they
can also have a second port which handles all the interrupt messages
between them and knows how to send and receive the messages in an
appropriate way. That way I don't have to reinvent the PioPort, mess it
up trying to make it work with interrupts, or mingle the two systems.
The next thing I thought of was that it would be handy to make this
part of the IntDev class which all (A)PICs already inherit from and
which fits this type of functionality. The PICs don't actually
communicate on the system bus, but they can ignore the interrupt port
and not attach it to anything and it would work fine. This could also
hook into the same mechanism already used to trigger interrupts through
the IntDev base class, so it could simplify things there too.
The problem with this otherwise pretty nice setup is that by adding
a port to IntDev, I think I have to make it a MemObject. Having multiple
inheritance of an IntDev and a (Basic)PioDevice was fine since the
IntDev didn't have any other bases or weird constructors or anything
like that. If it becomes a memobject, however, then there will be a
diamond in the inheritance hierarchy through the two bases back to
MemObjects and below, and I also remember getting constructors to work
in this sort of situation was a real pain.
It'd be a real shame not to be able to set things up this way, or to
even have to undo the IntDev/IntPin mechanism I have, so my question for
you guys is how I can get this to work. Can I get away with not making
IntDev a memobject? If not can I get the multiple inheritance to work
without causing a lot of grief somehow?
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
