BASIC CONCEPT FOR ACCESSING DISK CARTRIDGE FILE
The files sit on an SD card, from which the operator selects one to be mounted on the disk drive. When the actual disk drive in the IBM 1130 is switched on, it has a dummy cartridge inserted which spins up. As it hits speed, the drive goes ready and the software on the 1130 begins to position the arm and attempt to read or write words.
My logic in the diskmodel module will know when it needs a particular word of the disk cartridge image in order to stream the appropriate bit pattern into the actual disk drive hardware and eventually move into memory in the 1130 system. The address of the cylinder, head, sector and word that is needed is used to figure out the byte index into the virtual cartridge file. That index is added to the start of the file, which was memory mapped in the Linux system, in order to read that word from the Linux system memory and send it over the bridge to our FPGA logic.
The challenge is that the FPGA can address memory on the Linux side but it is addressing physical memory, not virtual memory. The file was mapped to virtual memory, which may be paged into noncontiguous areas all across physical memory. It can move at any time as other activity in the system forces old pages out.
HOW I MIGHT RESOLVE THIS COMPLICATION
There are three steps to this process, in order to have an address I can send to the FPGA that points at a contiguous block of physical memory pages where the virtual disk cartridge file is mapped. First is to ensure I have the 1MB block as continuous memory. Second is to ensure that my file memory mapping is assigned to the exact same range of virtual addresses. We must verify that the mapping remains 1 to 1, that is that a given virtual address has the exact same physical address at all times. Third, I have to be certain that the entire file is populated so that the contents of the file are paged into the physical memory already, so that when I read the physical memory I am sure I am seeing the contents of the file mapped to that address.
The Linux system reserves a large block of contiguous memory as part of the Contiguous Memory Allocation process, that block divided up and given to various device drivers and other functions that require physically adjacent pages. My needs are only for 1MB, whereas the system should have substantially more than that available after bootup.
The system call that memory maps a file to virtual address - mmap() - has options that can insist that the map start at specific addresses unless they are already taken. I will have assigned by 1MB block from physical memory at boot up, thus I can point the mmap() at this location to get the file placed properly. A parameter used to request this is MAP_FIXED_NOREPLACE.
The Linux system will preread all of the file and thus ensure it is available in physical memory by means of the MAP_POPULATE parameter however that requires that this file become a MAP_PRIVATE type. The problem with the private type is that when a write is done to the memory location, it is not written back to the disk file on the SD card automatically. Further, this suggests a 'copy on write' semantic which might assign a different noncontiguous page for this address once we update it.
The solution to the last issue may be the use of the msync() call once the virtual disk cartridge is unmounted - in other words once we see that the drive is no longer holding the heads down either because of the operator switching off the drive or due to some error we detected.
There are a number of assumptions that are necessary in order for all of this to work as I desire. It will take some careful testing until I am certain that I can make this work properly. The alternative is an uglier mechanism where application code in Linux must take each transaction and deal appropriately with the virtual cartridge image file, perhaps keeping a 'dirty sector' map and flushing the sector back to SD card whenever I see a request in another sector.
No comments:
Post a Comment