You will introduce a device driver into the Minix system. This shal...

You will introduce a device driver into the Minix system. This shall be a driver for a character device which stores an integer in one of five slots when write() is called, and will return the integer when read() is called. The ioctl( ) call will also be implemented, and should be able to choose between any one of five data stores (integer-sized) to use, and should be able to clear the integer from a specified slot.
You may start from the “clean” version of Minix. Here are some instructions to get an initial shell of the device driver in place. There are some instructions on the Minix 3 developer’s site describing how to add a very simple device driver to the system, so that is a good place to start. However, instead of adding a ‘hello’ driver to the system, use the current ‘hello’ driver as your starting place:
# cd /usr/src/minix/drivers
# cp –r examples homework
# cd homework
Here, edit the Makefile to change “hello” to “homework”, and the change the ‘hello’ directory to ‘homework’; the go into the homework directory and change hello.c to homework.c.
# vi Makefile (edit Makefile to change all instances of hello to homework)
# mv hello homework
# cd homework
# mv hello.c homework.c
And, here, also edit the Makefile to change “hello” to “homework” everywhere. Then, you can test building it:
# make
compile homework/homework.o
link homework/homework
# make install
install /service/homework

At this point, do some general cleanup (change or delete the hello.h file, and perhaps change all instances of ‘hello’ in your homework.c file to ‘homework’) to get ready for your changes. Next, you need to make sure your driver is in the system configuration. Edit the /etc/system.conf file (this time, not in /usr/src) as discussed in the Minix 3 device driver development page; again, you can copy the entry in that file for ‘hello’ and paste it at the end, changing ‘hello’ to homework. The other fields in that entry can be left as is. Then, you need to create a character special device file that provides the user mode entry into your device driver. Create it with the ‘mknod’ command as specified in the documentation; and use major device number 65 (which appears to be otherwise unused).
# mknod /dev/homework c 65 0
#
Then, you can start your new service using the ‘service’ command:
# service up /service/homework –major 65
Hello, world! (or “service up /service/homework –dev /dev/homework”)
# service down homework
#
With this in place, you can then start to modify the driver.
You will be able to: • Build a character device driver in Minix • Install the device driver into a running Minix system • Exercise the capability of the device driver
You must submit a new device driver within the Minix system, and some small user level applications that will exercise the device driver. The details on these follow.
You shall add a device driver to the Minix operating system.
a. This driver shall be called ‘homework’. One of the nice things about Minix is it has the ‘reincarnation’ server, so when your server is built and written, you do not have to reboot your system to start and to test your driver. You can use the “service” commands as described above and in the Minix 3 developer site.

b. This shall be a driver for a character device which stores an integer stored in one of five slots when write() is called, and will return the integer when read() is called.
i. For now, if no integer has been written to the device, the read() call returns whatever is in the slot (be sure to initialize the slots to 0). Future assignments will differentiate between the slot containing 0 and an uninitialized slot, so you may want to put that logic in now (see HIOCCLEARSLOT below).
ii. The read() and write() calls can only transfer 4 bytes. If a read() or write() call requests less than 4 bytes, those calls will return EINVAL. If the requested size is greater than 4, you should silently limit the transfer to 4 bytes. On success, the read() and write() calls will return 4 (representing 4 transferred bytes), regardless of the number of bytes requested in the call.
iii. Note: this driver, unlike the exemplar ‘hello’ driver, this driver is not returning a string when you need to keep track of where you are in the string as you are reading from the driver. Thus, the ‘position’ parameter passed in does not need to be used.

c. Your driver will support the ioctl( ) call. Three ioctl commands should be supported:
i. HIOCSLOT shall take an argument that specifies which slot should be used. Only integers between 0 and 4 should be accepted; if the argument is outside the range, print an error to the console and make sure the system call returns the proper error code.
ii. HIOCCLEARSLOT should set the current slot to ‘invalid’ and set the value of the slot to 0.
iii. HIOCGETSLOT should return the current slot index (should be between 0 and 4).
iv. The definitions of these ioctl’s needs to model other ioctls (e.g. /usr/include/sys/ioc_*.h). There are two macros to define the ioctl’s we will need to use: _IOW (devcode, number, type), and _IOR (devcode, number, type). The devcode is a single character that ties the ioctl constant to our driver; use ‘h’ for our driver. The number isn’t too important other than you need to make sure it is different for each of the ioctl’s. The type is the data type expected for the third parameter of the user’s ioctl( ) call; using u32_t should be fine. You must put these definitions in /usr/include/sys/ioc_homework.h. d. What should the open( ) and close( ) calls do? e. Write some your test programs (to read, write, and select/clear slots). I will provide some samples. Make sure you can compile your test programs with no errors. The test programs should open the device via the character special device file that you create called “/dev/homework”.