Let me ask you a different question. Suppose I write the following statements

dma = bus.slave
dma = bus.slave

Note that the same port is assigned a peer port twice. How many bus ports will
be created in actual? I think two bus ports will get created and one of them
will not have a peer port and this would result in a segmentation fault at
run time. This is what is happening right now with ruby full system as well. 
IDE disk's dma port is assigned a peer port twice.

Is this intentional?

There is no convenient way of specifying the number of vector ports up front, but I am fairly certain we check that the peer is not set when assigning it, so the second line should cause the Python configuration to complain. If not, we can easily add it. So in essence, yes it is intentional that the VectorPorts grow with assignment, but we could call fatal or similar when a peer is already set in the Python Port class.

If we do that, your example would terminate at the Python stage as intended. The problem then becomes to remove the double binding. Why is the dma port assigned twice? Can we easily remove it? Why is it not done as part of attachIO?

Currently a warning gets printed about over writing some port with some thing, and
afterwards the simulation ends with a segmentation fault. Is is not possible to 
nullify the effects of the first statement, and only keep the effects of the second 
statement around? As of know, I do not think it is straight forward to prevent this double
assignment from happening.

Since it is very isolated, I would suggest we make the warning a fatal and strictly forbid the double port binding. That makes it less ambiguous and less prone to misunderstandings in the future. Could you maybe shed some light on why it is difficult to prevent it from happening in this case?

I think Ruby, as of now, cannot allow pio accesses to flow through it. I have talked to Brad
about this before, and it seems to me that current implementation would have to be enhanced.
I don't know what config port is about.

I was just thinking...if the config and pio request and responses do not go through Ruby, then can we not do the same for the dma port requests and responses? Since Ruby does not do general memory-mapped requests/responses for the former, we could simply connect also the dma port to the bus that is used for the config and pio port, could we not?

I believe we can, but I don't have a say on what should be preferred.

Andreas, can you comment on how these three types of accesses differ from each other?
With a better picture, I might be able to able to allow pio and config requests to go
through Ruby.

The pio and config port are memory-mapped slave ports (much like a memory), but instead of storing data they read/write to registers that affect the behaviour of the device. Hence, they receive requests and send out responses.

The dma port is a master port (much like a CPU inst/data port), and it sends out read/write requests and expects them to be routed to a slave based on the address, and responses to come back when necessary.

Let me know if there is more information you would like about their functionality and the assumptions.

Can you draw a diagram to depict what you wrote?

I understand the urgency, and if we are indeed going with this fix for now, then I'd suggest we create a list of dma ports rather than a list of dma devices. That is, do not add the ide device to a list, but rather the ports that are to be connected either to ruby or to the classic memory system.

This would necessitate making changes to all the files protocol config files 
present in configs/Ruby/. Andreas, is there any reason why you suggest having
a list of ports?

If there are other masters (or master ports) on the IO bus then they would have to be connected as well, and there might be master ports that are not named "dma" but something different. Having an array of ports would be more general, and would simply connect what is in there either to Ruby or to the IO bus.