This 3-person group project is to learn how system calls are implemented by implementing a few yourself. To do this, you will have to modify Linux kernel source files. The Linux kernel is written in C, not C++, and so you must do this project in C.
We have seen that most Unix-variant operating systems are layered systems, with user-level programs at the top layer, and the OS kernel at the bottom layer, just above the host computer's actual hardware.
Our previous assigments have involved writing code that runs at the user's level -- in user mode. In this assignment, we will for the first time write code that runs at the kernel level -- in supervisor mode. As such, the code you write will have full control over and access to the kernel, its data structures, and the machine's hardware, including priveleged instructions.
Because the kernel is the foundation of the operating system, an error in the kernel's code may render the host computer unuseable. Since
Instead, we will use the virtual machine approach we saw earlier in the course. More precisely, you will run your own personal copy of Linux on top of a virtual machine called VMWare, which is running on top of the copy of Linux that is running directly on your machine's hardware:
In this "top" copy of Linux, you will have the root password, and thus can be the system administrator, without "endangering" anyone or anything else in the lab.
To work on this assignment, you must thus run VMWare, and then boot your own copy of Linux to run on top of VMWare. To store your own copy of Linux, we have provided you with what VMWare calls a virtual disk image -- a special file that VMWare treats like a disk volume. Your virtual disk image has been preloaded with a copy of Linux. By specifying this disk as a boot device for VMWare, you can boot your own copy of Linux, on top of VMWare, and login as its system administrator. You may then modify the kernel of this "top" copy of Linux at will, without harming the kernel of "bottom" copy on which VMWare is running (and which is used by the students in other courses).
By the time you read this, your VMWare virtual disk should be in your home directory. Since your home directory is available on each machine in the Systems Lab, your virtual disk will be accessible from any machine in the lab that Chris has set up to mount the home directories. You can thus work on this assignment from any of those machines. You should read these directions, taking special note of how long kernel recompilations may take. This document also describes your login information.
Your VMWare virtual disk should contain a full installation of Linux, plus the C source code for the Linux kernel, in the /usr/src directory. By modifying this kernel source code and then recompiling your kernel, you can change its behavior. Besides altering the existing kernel source code, you may also access or alter existing kernel data structures, create new data structures, write new kernel functions, and so on.
Creating a system call for Ubuntu 184.108.40.206-custom involves three steps:
.long SYMBOL_NAME(sys_*)in /usr/src/linux/arch/x86/kernel/syscall_table_32.S. Again, be sure to follow the naming conventions of the other entries in this table, and use a descriptive name.
Plan of Action.
In the steps below, all paths assume a starting point of /usr/src/linux/.
Note that kernel recompilations are relatively time-consuming, as are reboots, so you want to minimize your recompilations.
One way to do this is to invest time in a quality design so that you can focus on coding an already correct algorithm. If you try to use the compiler to debug a poorly designed algorithm, you are unlikely to complete this assignment in the allotted time.
Another way is to implement absolutely as much as you can in a standalone, user-level (i.e., regular) C program before you try it in the kernel. Find all the bugs in your code before you insert it into the kernel, if possible.
Another way is to design and code in pairs. When it comes to avoiding and/or finding errors (logic or syntax), two heads may be much better than one. Normal debuggers run in user-mode; so they are essentially useless when it comes to debugging at the kernel level. Debugging a logic error thus consists of inserting output statements (printk()) into your source, recompiling, and tracing the output. Given the time required to recompile, it is essential that you minimize recompilation; so you should make every effort to ensure that your logic is correct ahead of time.
Another way to save (a little) time is to write a shell script to perform the copy operation used to install your new kernel following each compilation.
If you get stuck, come and see me for some suggestions.
As in any project, you are to use descriptive identifiers, and in-line comments that explain any 'tricky' parts. You should document the changes you've made at the beginning of any file you modify, including the author, date, and purpose of the modification.
Each team should submit to one team member's directory in
/home/cs/232/current/<yourid>/proj4/ the following:
To save disk space, please delete parts of large source files, leaving the context surrounding your modifications. When you do this, please INSERT TEXT INTO YOUR SCRIPT FILE TO highlight your modifications (e.g., where extraneous stuff was cut out), so that the grader can find the good stuff easily. E.g., you might put this into the script file:
LOTS OF STUFF CUT OUT OF THE COMPILATION OUTPUT ABOVE.
If there is controversy about how much an individual on the team contributed to the project, each individual may submit their own
grading.txt file into
Due date: Thursday, Apr. 30, at 11:59 pm.
Warning: This is the most time-consuming project of the semester. You will likely need the entire time to get it working correctly. Begin work on it immediately!
Calvin > CS > 232 > Projects > 4