Program 2: New System Call

CS 3210 Design of Operating Systems
Spring 2000 * Hutto
Georgia Tech College of Computing

DUE: 1:35 pm (class time) Tuesday 8 February 2000

For your second programming assignment, you will add a new system call to your Linux kernel as described in Beck 3.3.4. In addition, you will write a user-level application to test your system call and use the strace utility to visualize the invocation of your new system call. Running a user-level application on your Skiff board and executing strace will involve remote mounting an NFS directory on your Skiff board. You may add the simple semop() sysem call described in Beck or devise an interesting system call of your own choice. As extra credit, you may implement the same system call  as a dynamically loadable kernel module.

Jason's tips for this assignment.

Step 1: Add the System Call

You can mostly follow the instructions in Beck but there are a couple of caveats. 

• First, if you add the semop system call, be sure to call your new system call sys_mysemop() or something distinctive. There is already a sys_semop() in the standard kernel as part of the System V IPC mechanism! 
• Second, instead of arch/i386/kernel/entry.S you will need to modify arch/arm/kernel/calls.s. The syntax is a bit different but you should be able to figure it out.
• Third, Beck's semop code has the following line:
  
      if ( current->signal & ~current->blocked )
  
  This will not compile properly under the 2.2 kernel. The blocked and signal entries were previously just long values that functioned as bit masks. In the 2.2. kernel these fields are now sigset_t which on ARM is a struct that contains a two element array of long. sigset_t is manipulated using some standard functions described in Maxwell Chapter 6. Start by commenting these lines out of your code. Then when you get the basic call working, try to identify the appropriate sigset_t functions to replace the above code.

Make sure you understand how Beck's semop implementation works! Don't just type the code in blindly. You should create a new file to contain your new system call as Beck describes. Be sure to add the new file to arch/arm/kernel/Makefile.

If you'd like you may devise a system call of your own. Just make sure what you hand in carefully describes the behavior of your new call. (Basically write a man page.)

Step 2: Compile and Load the New Kernel

Follow the instructions from the previous assignment.

Step 3: Write and Compile a Test Program

You will need to exercise or demonstrate your new system call. I call a program that demonstrates some other functionality a "driver". If you implement mysemop() then you will need to demonstrate that an application can correctly acquire and release the semaphore and that an attempt to acquire a busy semaphore will block the process until the semaphore is released. When it is released by the first process, the second (blocking) process should wake up, acquire and then release the semaphore. You can do this with a single application does an acquire, waits a bit and then does a release. You can start one instance up and watch it acquire and release the semaphore. If that works, then start another instance of the same program while the first is waiting. Call it myapp.c. You will need to use the _syscall1() macro as described in Beck to create a "library function wrapper" that assembles a software interrupt to trap to the kernel and invoke ENTRY(system_call). Make sure you expand _syscall1() globally in your C program. (Don't put it INSIDE a code block.) When you compile your new application, you will need to point to the newly generated include file <linux/unistd.h> which just points to include/asm/unistd.h in your modified source tree.

Step 4: Remote Mount

Let's assume that pwh is the account name of the designated team member. There should be a subdirectory on mustang:/hl1/pwh with a large disk quota. To remote mount in the Skiff lab, make sure your ethernet patch cable (not the cross-over cable) is plugged into the appropriate port of the ethernet hub in the lab. (See the Team Assignment web page for your port assignment if you don't remember.) Boot your Skiff board and select some (preferably empty) directory. There are several existing directories on the standard root filesystem you can use: /skiff, /mnt, /spare, /marvin or you can create your own. mustang exports /hl1 and all it's subdirectories to all the machines in the College. To mount the subdirectory pwh on the "mount point" /skiff in the Skiff lab just say:

mount -t nfs mustang:/hl1/pwh /skiff

On your home system, you will need to setup an NFS export. Jason has written up some details on this process.

Step 5: Execute Your Test Program

You will need to place your cross-compiled test driver (myapp) in your mustang directory. From the Skiff board just say something like:

/skiff/myapp

Step 6: Run strace

Review the description of strace in Appendix B.7 of Beck and the man page on any of the Linux machines in the Intel lab. Try strace on a variety of commands on a Linux machine in the Intel lab. You can use the -e option to trace a specific call or set of calls. To view your new system call you can say something like:

strace myapp

You can find strace in mustang:/hl1/strongarm-linux-lib/bin/strace (though this version hasn't been tested yet).

Step 7: Schedule a Demo Time with Jason

Any time prior to the due date, get in touch with the TA Jason Lunz (j@cc.gatech.edu) to schedule a brief demo to showoff your shiny new Linux kernel! For the demo, you need to run strace on your test app with your new kernel to demonstrate your system call. Bring printouts of any source code you have introduced or modified.

Step 8: EXTRA CREDIT: Implement a Kernel Module

Ori Pomerantz has written a good, up-to-date book "The Linux Kernel Module Programming Guide". The book is available online as part of the Linux Documentation Project. It's a bit weak on the background but gives you very good hands-on instructions and demo programs. Chapter 7 "System Calls" details how to add a system call as a kernel module. If you want a bit more challenge, work out the details of installing your system call as a kernel module. We will talk more about kernel modules later in the semester.

Odds and Ends

The standard late policy allows you to turn in assignments up to one week late for a modest 10% penalty. Beyond that, you need a REALLY good excuse. Having said that, I expect there to be lots of unexpected problems that will require extensions and postponements. Stay tuned to the newsgroup for late-breaking details.

I'm going to have a very open collaboration policy this semester. Feel free to discuss things with anyone but you must ensure that everyone in the team understands everything submitted for grading and that each team member can explain and reproduce any part of the assignment solution (given enough time) if asked! Grading assignments will usually involve a live demo. Expect us to ask some questions

What should you do when things go wrong? Read the assignment, review the relevant reading in the texts and handouts, ask your teammates for help, post to the newsgroup, involve other class members, come to office hours, use resources on the Web, find a local Linux guru who will share some hard-earned wisdom. Remember, your mother loves you...

-- Good luck!