One thing that I don't think has been mentioned is that the guest OS being run under SIMH might not take kindly to data changing on these new devices that are being proposed.
I would expect the guest OS doesn't expect things to "magically happen", because it (quite rightly) believes it is the only thing that is capable of doing that. So any sort of data from the device that is cached by the guest OS (maybe directory entries, block allocation data, or parts of a file that was recently read) would suddenly risk becoming invalid. That's a sure-fire recipe for chaos. On something like a SCSI-clustered VMS system, while there were multiple hosts attached to a common SCSI bus, there was also cluster communication taking place another communication channel like Ethernet to ensure that all nodes had a consistent view of what was going on with each SCSI disk. Dual porting is a tricky thing, but doing it without properly notification mechanisms or processes to ensure on-device and in-memory consistency is asking for trouble ! Having the guest OS shut down, then making changes to the contents of the new device, and then restarting the guest OS via a reboot with no further changes from an external source would be one way of doing this in a purely process-driven fashion. This is essentially what SIMH does when attaching devices prior to starting the guest OS. _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
