In Project 2, you are required to add a system call to the Linux kernel and write a small program to test this system call. Before you begin, create a custom kernel specific for Project 2, starting with a copy of the pristine Linux kernel linux-2.4.21-20.EL. Name your custom kernel for Project 2 as linux-2.4.21-20.EL-GLUSRNM-project2, where GLUSRNM is your UMBC GL username. (Replace the "custom" in Makefile by "-GLUSRNM-project2".)

Part 1: Adding system calls to the kernel.

• The kernel variable max_threads initialized during booting to have the maximum number of processes (more precisely: the threads) that the system can support.
• The kernel variable nr_threads contains the number of currently running threads.
• Write a system call to get these values of these kernel variables. The signature for your system call must be

        int getThreadInfo(int *threads_max, int *threads_running)

The system call should return 1 if successful or 0 if there is any error. Note that the variables max_threads and nr_threads are in the kernel space; where as, the arguments of the system call are addresses in the user-space where it needs to put the information.

Make sure that your system calls have exactly the same signatures as above, (since otherwise our test programs will fail!) Function/variable names are case sensitive. Any kernel panics/failures will result in a very substantial reduction of points. Please go through the hints and pay particular attention to functions you use to copy to/from user/kernel spaces.

Please have the implementation of the system call in separate files.

Part 2: User mode driver and test programs

Hints

• Linux Resources
  • Linux source code navigation can be found at  http://lxr.linux.no/source. This allows you browse through the kernel sources, search for where variables/identifiers/functions are defined/used, etc.
• How to add Linux System Calls:
  • Adding a System Call
  • Kernel Korner: System Calls
• Refer to LKP, section 3.3.
• Recall that a system call is a software trap or interrupt. This means that when adding a new system call, you will need to update the system calls table (i.e. the interrupt vector) with new entry/entries, and generate stub(s) that will be used by user programs. Look for files arch/i386/kernel/entry.S and inlude/asm/unistd.h, and look for the macros _syscall1 and _syscall2.
• In the critical section of the code you write (e.g. when you access the new kernel variables), you should try to avoid any race conditions, perhaps by disabling and enabling the interrupts.
• You will need to dereference a user space pointer in the kernel when trying to pass a value back in the argument of some of your functions. You may want to look at the functions  copy_to_user(), copy_from_user(), strncpy_user(), strnlen_user(), etc for help with this. 

What to submit

• A Project Report describing your detailed approach in solving this assignment, (what did you do? how did you do it? why did you follow that approach? etc). The Project Report is an IMPORTANT component of your overall project. Follow the guidelines in System Design Document Template for preparing your project report. The Project report must be a single PDF file with filename "project2report.pdf"; Yes! this is CASE-SENSITIVE and NO EXCEPTIONS!.
  The Project Report carries 10 out of the 75 points for Project 2.
• The patchfile patchPrj2.diff for your changes to the kernel source. As always, it is a good idea to verify that the patch is correct. A bad patch file may not patch properly and we may not be able to compile your kernel to evaluate it.
• All of your source code and header files (for the functions you developed and test programs). These could be separate files or be part of existing kernel files.
• The updated entry.S, unistd.h and kernel Makefile
• The driver program(s) (driver.c and driver.h files) and the Makefile to compile the driver program.
• Sample output showing the execution of your driver program (this can be obtained by running the "script" command and submitting the file "typescript" generated as output by script.
• A README file (explaining how to compile/run your program)