OK, so maybe my example was a bit more high-level than what folks are discussing, but even for a "bunch of bits/bytes" device, synchronization still has to be considered here (just as it would for access to common data when writing a multi-threaded program).
As long as the guest OS has exclusive access to the device (preventing the host OS doing reads or writes) , or the host OS has exclusive access to the underlying host file representation (preventing the guest OS from doing reads or writes), then things are OK. The minute that both try to access it, with one reading and the other writing, it all falls apart because there are lots of ways to corrupt the data stream mid-way through either operation. -----Original Message----- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Ken Cornetet Sent: Wednesday, 20 April 2016 1:43 PM To: simh@trailing-edge.com Subject: [External] Re: [Simh] Way out idea for simh The guest OS wouldn't care, because the guest OS wouldn't see it - there isn't a guest OS file system on the disk. The *only* thing reading or writing the bits in the guest world is the custom utility program. For all I know, there may be some guest OSes that insist on having a native file system on a disk device. RTE and unix (the only two simh OSes I am familiar with) are perfectly happy to have a disk with no file system and let you access it as a collection of blocks. If an OS insists on a native file system on the disk, then this scheme wouldn't work. -----Original Message----- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Armistead, Jason . Sent: Wednesday, April 20, 2016 1:31 PM To: simh@trailing-edge.com Subject: Re: [Simh] Way out idea for simh 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 _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
