Comp 430 Project #1

Comp 430 Project(s) #1: Shell and System Call

Introduction

This project includes two independent components. The first is to implement a simple SHELL program, and the second is to add a system call to your kernel. Each of these sub-projects includes a required portion, as well as an opportunity for extra-credit.

SHELL

Complete the shell project described on page 121 of your textbook. You are not required to complete the second portion of the project which involves creating a history feature for your shell. You may implement the history feature for extra credit.

The file shell.c provides some starter code that will be useful in completing this project.

The file signal.c provides an example of setting up a signal handler that will be useful if you decide to implement the history feature.

Adding a System Call

I'll leave it to you to work out the details. As a way of getting started, I suggest reading Chapter 5 of Linux Kernel Development. It does a good job of explaining system call implementation in Linux. For some more specifics you can refer to the following two links:

The instructions presented in the first link worked pretty well for me with some exceptions:

The _syscallN macros no longer exist.
The kernel tree has been reorganized. There is no longer an i386 directory, instead there is a x86 directory that contains code for both x86 and x86_64 architectures.
It isn't necessary to futz around with creating new directories and Makefiles for your new system call. You should be able to just add your system call to kernel/sys.c .

Your system call can do more or less whatever you want. It doesn't need to do anything useful at all. It does need to meet the following specifications.

It must perform a printk statement that looks something like the following:
printk(KERN_DEBUG "comp430 syscall completed!\n");
(You'll need to #include <linux/kernel.h> )
It must not crash the kernel.

Once you have successfully compiled your new system call into the kernel, you will need to test it. Write a user level program that executes your system call and prints the return value. Any system call that the kernel does not recognize results in a return value of -1, so your system call should return something other than that when it works.

After you execute your system call, run the command dmesg in a shell. You should see the message that was printed by the printk statement in your system call. Refer to page 309 of LKD for more information on printk.

Your code for this portion of this project should follow the Linux kernel coding style guidelines.

The extra credit component of this project is to describe the chain of events that occurs when a system call is made from a VM in VirtualBox, and how that differs from system calls made directly to hardware.

Handing In

Your submission should take the form of a tarred directory as described in HW #1 . That directory should contain:

The source for your shell program.
A plain text README file documenting your shell project. This file should include your name(s), a short description of the project, instructions for running your shell, a description of any known bugs, and anything else I need to know to evaluate your submission.
The user level program for testing your system call.
A patch file representing your modifications to the Kernel. I'll test your submission by applying this patch, so you should test it before you submit it. Instructions for creating a patch can be found in the file linux-2.6.24.3/Documentation/SubmittingPatches. There is an unmodified kernel tree located in the disk image comp430_kernel.iso available from the DVD, or in /var/scratch/comp430-shared/ on tron. Be sure to make clean and make mrproper in your kernel directory before you make the patch. (Be careful with make mrproper, it will delete your .config file.)
The patch file should be smallish -- probably fewer than 100 lines.
A plain text README documenting your system call project. Once again, you should include information on known bugs, as well as anything else I need to know to evaluate your work. If you choose to do the extra credit portion of this project, you can put that work into this file.

Grading

The two projects will be weighted equally. Each will be graded as follows:

Comments, documentation, code formatting, and proper submission format	20%
Coding style	20%
Functionality	60%
Possible extra credit	5%

This page is maintained by Nathan Sprague nsprague{at}kzoo{dot}edu.