CMSC421Principals of Operating SystemsSections 0101/0201/0301 |
CSEE |
Project Due: 2 Oct 2002 at 11:59 pm
Design Document Due: 26 Sep 2002 at 11:50 pm
Extra credit: 26 Sep 2002 at 11:59 pm -- 10% of the graded earned.
Due date is extended to 8 Oct. Those who have it turned in on the original due date will get 15% extra credit of grade earned.
I built my project against the pristine kernel source for 2.4.19 from kernel.org. I have made several assumptions: /usr/src/linux is a symlink to the appropriate kernel source tree (i.e. /usr/src/linux-<hatever your version is>) /usr/include/linux is a symlink to /usr/src/linux/include/linux (I moved the old directory created during gcc's build to /usr/include/stock_linux) /usr/include/asm is a symlink to /usr/src/linux/include/asm (old directory moved as above)
In the past couple of week, The Linix Users Group has helped people to install the GNU/Linux operating system. I am providing links with instructions on how to compile and install the kernel. I assume that you have installed linux, or are in the process of doing so. This document will describe a new function that we want you to add to the kernel as a system call. The exercise is fairly straightforward, and you'll add in no more than 50 lines of codes/headers etc -- probably less. The idea is to make sure you understand the mechanics of modifying the kernel.
I assume that you are already familiar with makefiles and debugging from classes such as CMSC 341. If not, this will be a considerably more difficult project because you will have to learn to use these tools as well. (Kernel debugging is different from normal debugging!)
Please make sure that the group is identified in the README you turn in, and that only one member of the group submits the project!
You will need to hand in all of your code and documentation using the Blackboard system available on the GL cluster. In particular, hand in the tar/gzipped version of your new kernel. To build the file to turn in, you have to make a patch file.
To submit project 1, you do the same thing that "real" software distributions do in the unix world -- create a patch. A patch is a file that notes differences between two files or directories. This file can be created via the diff command, and be used via the patch command. I encourage you to look up the man pages for both of these. In order to create the patch, assume that a "clean" version of the kernel (i.e. what you get when you untar the distribution with *no* changes) is in the directory /usr/src/linux, and your own modified kernel is in /usr/src/mylinux.
I am enforcing both deadlines to ensure that people don't leave the project until the last minute. There is enough time to do the project, but not time to waste. (I guarenteee You are, of course, welcome to visit either the faculty or TA office hours for help; however, one of the first things we'll ask for is your design documentation (unless you're asking for help with that!!!). You may make changes to your documentation before the full Project #1 submission; however, the design portion of your grade will depend heavily on the design document you submit on Sep 26th.
Your design documentation, typically 1-2 pages for a project of this size, should include the basic design of your software (what modules will you write, where will you make changes to the kernel etc.), a timeline, as well as details on the testing that you plan to do to ensure that your code works.
It is true that most kernels do not need a social security number
for anything, but who knows, we might start a fad!
=;-)
What is
important that is that whenever the need to modify the kernel
occurs, it is done the same way.
We should be able to invoke your function as:
You must also create two small C programs. The first one will simply get the user's SSN (only the last four digits), and set the kernel variable using the input value. The second one will retrieve the value from the kernel variable and print it out on the screen. Obviously, these are tiny programs. They simply verify that your modifications work. By having separate programs, there is no issue that you are correctly setting and getting the value. (Remember the user -- NOT YOU -- are providing the value to be stored and the TAs will be selecting that value!
You will probably need (though maybe not all of them):
kernel-2.4.18-3.src.rpm 33510 Kb Thu Apr 18 14:46:00 2002
kernel-pcmcia-cs-3.1.27-18.... 1197 Kb Wed Apr 17 04:35:00 2002
kernel-utils-2.4-7.4.src.rpm 238 Kb Wed Apr 17 04:35:00 2002
The grading for the project will be as follows: 40% design, 60% implementation. We have structured the grading in this way to encourage you to think through your solution before you start coding. If all you do is to work out a detailed design for what you would do to address the assignment (and if the design would work!), but you write no code, you will still get almost half of the credit for the assignment. The implementation portion of the grade considers whether you implemented your design, ran reasonable test cases, developed the two driver programs, and provided documentation that the TA could understand. Part of being a good computer scientist is coming up with simple designs and easy to understand code; a solution which works isn't necessarily the best that you can do. Thus, part of the design and implementation grade will be based on whether your solution is elegant, simple, and easy to understand.
5% of your implementation grade will come from adherring to the coding standards in the two following pages ( This will be all or none, so follow them consistently!):