Stage 18 : Disk Interrupt Handler (6 Hours)

In this stage, we will introduce disk interrupt handling in XSM. In the previous stage, we used the loadi statement to load a disk block into a memory page. When the loadi statement (immediate load) is used for loading, the machine will execute the next instruction only after the block transfer is complete by the disk controller . A process can use the load statement instead of loadi to load a disk block to a memory page. The load statementin SPL translates to LOAD instruction in XSM.

The LOAD instruction takes two arguments, a page number and a block number. The LOAD instruction initiates the transfer of data from the specified disk block to the memory page. The XSM machine doesn't wait for the block transfer to complete, it continues with the execution of the next instruction. Instead, the XSM machine provides a hardware mechanism to detect the completion of data transfer. XSM machine raises the disk interruptwhen the disk operation is complete.

To initiate the disk transfer using the load statement, first the process has to acquire the disk. This ensures that no other process uses the disk while the process which has acquired the disk is loading the disk block to the memory page. eXpOS maintains a data structure called Disk Status Table to keep track of these disk-memory transfers. The disk status table stores the status of the disk indicating whether the disk is busy or free. The disk status table has a LOAD/STORE bit indicating whether the disk operation is a load or store. The table also stores the page number and the block number involved in the transfer. To keep track of the process that has currently acquired the disk, the PID of the process is also stored in the disk status table. The SPL constant DISK_STATUS_TABLEgives the starting address of the Disk Status Table in theXSM memory.

After the current process has acquired the disk for loading, it initializes the Disk Status Table according to the operation to be perfromed (read/write). The process then issues the load statement to initiate the loading of the disk block to the memory page. As mentioned earlier, the XSM machine does not wait for the transfer to complete. It continues with the execution of the next instruction. However, virtually in any situation in eXpOS, the process has to wait till the data transfer is complete before proceeding (why?). Hence, the process suspends its execution by changing its state to WAIT_DISK and invokes the scheduler, allowing other concurrent processes to run. (At present, the only concurrent process for the OS to schedule is the IDLE process. However, in subsequent stages we will see that the OS will have more meaningful processes to run.)

When the load/store transfer is complete, XSM machine raises the hardware interrupt called the disk interrupt. This interrupt mechanism is similar to the console interrupt. Note that when disk interrupt occurs, XSM machine stops the execution of the currently running process. The currently running process is not the one that has acquired the disk (why?). The disk interrupt handler releases the disk by changing the STATUS field in the Disk Status table to 0. It then wakes up all the processes waiting for the disk (by changing the STATE from WAIT_DISK to READY) which also includes the process which is waiting for the disk-transfer to complete. Then returns to the process which was interrupted by disk controller.

In this stage, you have to modify the exec system call by replacing the loadi statement by a call to the Disk Load function. The Disk Load function (in device manager module), the Acquire Disk function (in resource manager module) and the disk interrupt handler must also be implemented in this stage. Minor modifications are also required for the boot module.

1.Disk Load (function number = 2,device manager module)¶

The Disk Load function takes the PID of a process, a page number and a block number as input and performs the following tasks :

1. Acquires the disk by invoking the Acquire Disk function in the resource manager module (module 0)
2. Set the Disk Status tableentries as mentioned in the algorithm (specified in the above link).
3. Issue the load statement to initiate a disk block to memory page DMA transfer.
4. Set the state of the process (with given PID) to WAIT_DISK and invoke the scheduler.

2.Acquire Disk (function number = 3, resource manager module)¶

The Acquire Disk function in the resource manager module takes the PID of a process as an argument. The Acquire disk function performs the following tasks :

1. While the disk is busy (STATUS field in the Disk Status Table is 1), set the state of the process to WAIT_DISK and invoke the scheduler. When the disk is finally free, the process is woken up by the disk interrupt handler.
2. Lock the disk by setting the STATUS and the PID fields in the Disk Status Table to 1 and PID of the process respectively.

3. Implementation of Disk Interrupt handler¶

When the disk-memory transfer is complete, XSM raises the disk interrupt. The disk interrupt handler then performs the following tasks :

1. Switch to the kernel stack and back up the register context.
2. Set the STATUS field in the Disk Status table to 0 indicating that disk is no longer busy.
3. Go through all the process table entries, and change the state of the process to READY, which is in WAIT_DISK state.
4. Restore the register context and return to user mode using the ireturn statement.

4. Modification to exec system call (interrupt 9 routine)¶

Instead of the loadi statement used to load the disk block to the memory page, invoke the Disk Load function present in the device manager module.

We will initialize another data strucutre as well in this stage. This is the per-process resource table. (This step can be deferred to later stages, but since the work involved is simple, we will finish it here). The per-process resource table stores the information about the files and semaphores which a process is currently using. For each process, per-process resource table is stored in the user area page of the process. This table has 8 entries with 2 words each, in total it occupies 16 words. We will reserve the last 16 words of the User Area Page to store the per-process Resource Table of the process. In exec, after reacquiring the user area page for the new process, per-process resource table should be initialized in this user area page. Since the newly created process has not opened any files or semaphores, each entry in the per-process table is initialized to -1.

5. Modifications to boot module¶

Following modifications are done in boot module :

1. Load the disk interrupt routine from the disk to the memory.
2. Initialize the STATUS field in the Disk Status Table to 0.
3. Initialize the per-process resource table of init process.

Compile and load the modified and newly written files into the disk using XFS-interface. Run the Shell version-I with any program to check for errors.