Improve support for disk images that get changed by other processes

[dansanderson]

Is your feature request related to a problem? Please describe.
I have projects that involve automated building of disk images, and it's often handy to test these disk images in Xemu. Right now, I'm restarting Xemu every time I re-build my disk image, using the command line to speed up loading of the disk: xmega65 -8 mydisk.d81

It would be nicer if I could reload the disk image from within Xemu while it is running, as if I removed the disk from the drive and inserted a new one. I would expect to be able to use the "Attach D81" menu option for this, but this fails in the case where I'm selecting the disk image file path that's already attached. Even though the disk image file has changed, it does not reattach the disk.

I also notice that when the disk image that is currently attached is changed by another process, Xemu forgets the contents of the disk and sees it as a disk with no files. Together with the lack of reloading, updating the disk image causes the disk to break until it is detached then attached.

Describe the solution you'd like
I imagine there's complexity in dealing with other processes making changes to attached disk images. In my case, I'm waiting until there is no disk activity to update the image, but I can see how updating the image during disk activity could be problematic. For example, I assume that the disk image file is updated at the end of a disk command that modifies the disk.

I don't see a harm in detecting an external change in the disk image file and automatically detaching and reattaching before executing the next disk command. This could be a a stat check at the beginning of the next disk activity. For example, I'd like to be able to type DIR with the old image attached, replace the file, then type DIR again and see new contents.

Describe alternatives you've considered
If automatic reattaching is impractical for a reason I can't think of, it'd be nice to have a faster way to manually detach and reattach, such as a "Reattach D81" menu option. Perhaps this option is only enabled when a change in stats is detected; otherwise it appears in the menu disabled.

Short of that, I should be able to "Attach D81" the disk path that is already attached and have this result in detaching and reattaching the image. It's less good that I have to select the file again, but at least this behaves as I would expect, and saves me the step of having to detach it first.

This is a good example of a case where it'd be useful to be able to send Xemu commands from a command line client while it is running. For example, the command xmega65 --client -8 mydisk.d81 would locate an already-running Xemu instance, detach unit 8, then attach unit 8 with mydisk.d81. (I'm vaguely aware that Xemu can accept serial commands from the mega65-tools. If that's the correct way to do this, please let me know! :) )

[lgblgblgb]

@dansanderson Hmm. That's an interesting topic. Internally, Xemu does not care too much if some other process modifies the disk image while it's being used by Xemu otherwise, as Xemu always reads/writes floppy sectors from/to the file, ie it's not cached internally or anything. So in theory, the modification should be transparent even now.

The bigger problem here - I guess - is not Xemu, but CBDOS itself (part of the MEGA65.ROM) as it's really not ready for the disk suddenly changing without its knowledge (and indeed it would be a miracle on a real machine, or a very bad thing, we can choose) ... CBDOS itself caches the BAM and maybe even the directory, I am not really sure, so what you noticed is not by Xemu but the ROM itself. Unfortunately I cannot do too much about that, at this level.

D81 mounting and disk drive handling even at only hardware and hyppo level (+ROM ...) is very complicated, now mixed with the fact that Xemu is an emulator and needs to override hyppo sometimes not to get D81s from the emulated SD card (-image) but some "external to the universe" (from Hyppo's view point) place, the only solution seemed to work that Xemu gets several (about half a dozen) ways to get various mount changes, and it tries to filter if there is a difference if the operation would be carried through and silently ignore if no, since there is no change then. That is the reason, simple remounting the same file name does have no effect since it's caught on that filtering mechanism which made it possible Xemu work at all in this form (don't forget that hyppo, ROM all thinks it's a real MEGA65 and does not know anything about emulation).

Sorry for the long explanation, I like to write a lot, even without actual need for it ;) Indeed, what you wrote can be a solution, though I am not sure how ROM reacts, ie if I try to simple produce a "disk change" event via the F011 FDC registers, so probably then ROM (CBDOS part) realizes that disk has been changed and it should forget its caches. And also indeed, a "reattach" or something menu point may be a solution, but I really should test this, if works at all.

But it also depends how you update the disk image. If you really open the same file and rewrite, thus in UNIX terminology the i-node is the same, then no problem. Surely if the update mechanism of yours only produce a file and moves that to the same name as the original one, it's another file technically, and the already opened file descriptor pointing to the old file still functions even if that data stream cannot be accessed by open syscall (but the new one). Even possible that this theory works very differently in Windows and UNIX-like systems btw, so then we would have some problem that some feature of Xemu is kinda differently works using one OS then an other. So I am still thinking if there is a better (albeit more complex) solution for this.

For the client-server model to locate running instance etc ... Well, it indeed looks fancy but "too futuristic" at this point of time at least :) Easiest would be to dedicate a signal (like SIGUSR1) to notify Xemu about changes, however again that problematic, as I am not sure if it works at all for the Windows port, surely it's OK for UNIX-like ports of Xemu (eg Linux and Mac versions). The problem always, that the solution should be, what is supported on all platforms, and usually this is the hard thing when we go deep into technical details like in this case, even the implementation of the given OS is important to be known.

Other than that, not so many software work like this, ie imagine a word processor or something that should be work when its files are externally modified meanwhile ;-P Ok, I admit, not the very same use-case, but you see, it's always a kind-of-problem in general to do so.

[lgblgblgb]

Preliminary idea implemented in the next branch: bee6e9d

The "uartmon" connection can be used to "remote control" Xemu. Currently there is a very limited, super quick, super ugly solution:

~exit causes Xemu to exit (not so much connected with the topic ...)
~mount0 causes to umount image in drive 0 (yes, no spaces/tabs/etc between word mount and 0)
~mount1 same for drive 1
~mount0disk.d81 causes to mount "disk.d81" to drive 0 (yes, no spaces at all ....)
~mount1disk.d81 same for drive 1

Currently, it's not so much possible to "remount", so it must be "un-mount" followed by "mount" ... The ~ (at the very beginning of the command, there is no space or anything after that!) is for marking the command "special" (ie, not usual MEGA65-compatible uartmon command).