Desktop/programs/SO_Software/students/~you
Follow the instructions above to complete the lab, but here is a substantial platform of code that will get you most of the way. This code is meant for the slackware2.4 vdi kernel image given in the VM_image handout directory and intended for use in virtualbox. The LKMPG for Linux 2.4 is still essential reading. All the handout code is stripped-down variations of the code in the LKMPG guide.
Note We'll go through the process of building a new kernel in class. The steps are outlined below.
pedagogictime.
I recommend you start working on the Lab 8 kernel implementation at the same time you are developing your queue design and prototype code. Your explorations of how to do the kernel version of Nutt lab 8 will inform how you want to do your prototype code. For instance, you will need to determine the scope of your prototype and exploring the kernel code might give you a better sense of how much you need to prototype.
At one extreme you might develop an event queueing data structure with the four specified system calls plus the scheduling and synchronization needed to run your prototype in multi-process mode. In this extensive prototype you might write a test harness that had a parent process set up and manage your event queues while generating many children to use the event queue concurrently.
On the other hand, you might discover that you don't need or want to prototype the entire multi-processing code, and decide to just test out your queueing data structure and system functions in single thread mode. In this approach you are trusting that you can figure out how to correctly and effectively use the built-in kernel scheduling and synchronization mechanisms when you get to working on the Lab 8 kernel code.
Keep in mind that you goal in building a prototype is to work through the design and implementation in a "safe" user mode programming environment so you can freely explore your design ideas and simplify your coding efforts when you get to the kernel. With goal in mind, the better you understand the kernel code you will be writing, the more directly you can determine what prototype code you need to write.
By the way, it is conceivable and even possible to skip the prototype stage and go straight to kernel programming to solve the problem. In the real world this is guttsy and risky - you might end up with nothing to show for your efforts because the problem was more difficult than you expected. On the other hand, it is also possible that you'll spend all the effort to build a prototype and discover that the kernel programming was very simple after all and maybe you didn't need any prototype code.
Work with each experiment until you understand the code and how the code is intertwined with the kernel. Some of the code uses kernel macros (usually in CAPS). Where are these macros defined and what do they do? The code makes kernel calls. Where are the kernel functions defined in the 2.4 kernel and what do they do? What kernel data structures are being used and how?
Change the code to make it yours. Take out my comments and put in yours. Reformat the code order to suit your preferences. Experiment with adding you own code extensions. Write real test programs for the modules, that is, other C programs that call the new system calls from C code. Try to break the code and propose improvements.
Extend the code to solve the problem specified in the Nutt lab 8. This will require you to support more than one event queue and have two new system calls to provide dynamic creation and deletion of wait queues. At this point you will hopefully be able to use some of your Lab 7 prototype code for that already creates and manipulates the queues according the specification for Nutt lab 8.
After you get your version of the LKMPG device driver working, go on to the Nutt Lab 10 and build the FIFO pseudo device defined in that lab. Be sure to write a good test program and, of course, produce a nice text file writeup to include in your directory that you tar and submit.