Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have a FAT formatted disk image which is set as one of the hard drives in bochs. It is mounted using the "mount -o loop" command so that I can put user mode applications on it and test them. I use this script to compile the program and transfer it to the mounted image:
The problem is that it takes some time before the file gets copied to the disk image. The first couple times I run bochs the old version of the file is still on the image. Once I run bochs two or three times, it starts using the version of the file which was just copied over. Anyone know why it does this?
justin wrote:The problem is that it takes some time before the file gets copied to the disk image. The first couple times I run bochs the old version of the file is still on the image. Once I run bochs two or three times, it starts using the version of the file which was just copied over. Anyone know why it does this?
Either:
The file system and loopback device fail to sync their cache/s to the disk image when it is unmounted (such that the disk image is up to date when "unmount" completes); or
You failed to unmount the disk image before starting bochs, and there's a problem with the loopback device's file locking (e.g. the loopback device should lock the disk image, and Bochs should give you some sort of "failed to open disk image - file is locked by another process" error).
I'd suspect the latter.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Brendan wrote:
You failed to unmount the disk image before starting bochs, and there's a problem with the loopback device's file locking (e.g. the loopback device should lock the disk image, and Bochs should give you some sort of "failed to open disk image - file is locked by another process" error).
Aren't the compiled programs for the OP's OS, not Linux (even though he is developing on Linux)? If he chooses to use the .exe extension for executables in his OS, why not? It's useful on a FAT fs where names are restricted.
iansjack wrote:Aren't the compiled programs for the OP's OS, not Linux (even though he is developing on Linux)? If he chooses to use the .exe extension for executables in his OS, why not? It's useful on a FAT fs where names are restricted.
Yes. This is correct. The three letters at the end do not matter.
TO OP: When I do on linux with qemu and loopback device, issue sync command flush the data to the image file and qemu can read the update image.
if your OS can write to the image it may however mess up the loopback if you do not disconnect it.
bluemoon wrote:
TO OP: When I do on linux with qemu and loopback device, issue sync command flush the data to the image file and qemu can read the update image.
if your OS can write to the image it may however mess up the loopback if you do not disconnect it.
Thanks. I fixed the problem by enclosing the "cp" statement with "mount" and "umount" statements. I wasn't aware that you had to unmount the thing.
Nessphoro wrote:
Well I don't see why one can't use an extension of say .elf. But that is op's choice and I don't really care.
You seem upset at my choice of extension. What is so much better about .elf?