Blocking Device Drivers in Minix and Memory Management
You will modify the device driver in Project 2 to support blocking reads. You will also provide some observations about the use of virtual memory in Minix.
For this device driver part of this project, you should build the new functionality in your image finished with in Project 2.
# cd /usr/src/minix/drivers/homework
# cp –r homework homework3
# cd homework3
Don’t change your Makefile in the new directory; your service will still be called ‘homework’.
# make
compile homework3/homework.o
link homework3/homework
# make install install /service/homework
You are now ready to make changes to this version of your homework driver.
After completion, you will be able to:
- Build a character device driver in Minix which blocks on a read() calls if no data is available
- Build a character device driver in Minix which unblocks multiple processes blocked in a read() when data is made available via a write() call.
- Exercise the capability of the device driver using provided test programs as well as test programs.
- Explain the use of virtual memory in Minix.
There are 2 deliverables, both within a modified Minix system. The first is the modified device driver within the Minix system, and the second are some small user level applications that will exercise the device driver. The details on these follow.
Part I - Device Driver Requirements
In this exercise, you shall modify the device driver you wrote in Project 2 as follows.
- If no integer has ever been written to the active slot in the device since the device was activated, the read() call will block until an integer is written into the slot.
- If the slot was cleared (HIOCCLEARSLOT) and was not subsequently written to, make the read( ) call block until an integer is written into the slot.
- The process blocked in the read( ) call should wake up when some process writes to the slot, and should then return the data in the slot. You should also handle the case where multiple processes are blocking on a read from the same slot (all should wake up and get the data).
- Hints:
- The tty driver in Minix is one driver that suspends and resumes processes. Looking there may help.
- If a function in the driver returns ENOREPLY, then there will be no message in response to the message sent to the driver. This will cause the process calling this function to block.
- To resume a process, you need to send a reply message to the original message. Fortunately, there is a function in the chardriver library called ‘chardriver_reply_task’ that can do just that.
Part II – Minix Virtual Memory
- The following questions relate the implementation of virtual memory in Minix 3.2.0.
- Minix 3.3.0 supports virtual memory. Create a user program called ‘mem.c’ in your minix root home directory that prints out the (approximate) addresses of the text area, the global data area, the heap, and the stack. Explain how these addresses demonstrate the use of virtual addresses in Minix.
- Does Minix 3.3.0 support a persistent storage ‘swap area’ on disk that allows Minix to either run a process that requires more than the amount of available physical memory, or to run more processes that can fit into memory? Explain your answer by creating a process or set of processes that use more than the available physical memory.
- Show where in the Minix source where the virtual memory mapping is performed, and explain.
Place the programs you used to demonstrate a. and b. in the directory /root/Memory in your Minix image submitted for this project.
