Handouts and Notes

• If not otherwise indicated, lab assignments are from the text Operating System Projects, by Gary Nutt.

• Lab Report Guidelines for submitting your lab project work.
• OS Images for VirtualBox (vdi files) and big
• Linux Kernel Source Code Index - A handy site thanks to Nik Nyby.
• The Linux Kernel Module Programming Guide
• Directory of all code samples
• Kernel Locking Techniques, an article by Robert Love in the Linux Journal.
• Anatom of Linux Synchronization Methods, an article by M. Tim Jones in IBM's DeveloperWorks.

• Here's the priority order of OS work for weeks 1-3 winter quarter.
  1. Lab 5 modules (nutt 4)
  2. Lab 6 syscall (nutt 5)
  3. Virtual Memory problems Chapter 8
  4. Read Chapter 9
  5. Chapter 9 problems
  6. Labs 4,3,2,1 from fall quarter

• Here's what's coming in weeks 4-9 winter quarter (not really in order).
  • One or more of Nutt labs 7,8,9, or 10 (Virtual Memory, Synchronization, Scheduler, Device Driver).
  • Chapter 10 Scheduling
  • Chapter 12 File systems
  • An exam covering all the text chapters and Nutt labs for both quarters.

• Here's how to get files from web posting onto your virtualbox 2.4 linux. This should be handy for downloading the tar files for the sample directories that are posted.
  1. Bring up the handout directory and see the URL.
  2. Do wget on that URL from inside your virtualbox linux.

• Save your large virtual machine vdi files in your Orca accounts where there is plenty of room. The Orca folders are available from Windows in the lab or from the unix machine ada or from off campus using the fileshare instructions posted on wikis.evergreen.edu.

  Desktop/programs/SO_Software/students/~you

• Here's a tip from Jeremy Parks that seems like a good idea, but I haven't tried it. Consider keeping a completely separate source code copy in a separate directory for each kernel version you modify and compile. You must create a symbolic link from /usr/src/linux to whichever source code you are currently working on. You you can use tar to create a new source code directory with all the proper symbolic links in place. Note that you don't need to do this if you are using modules and not modifying the source code.

• I added some new examples of using modules to the Lab 5 - modules sample handouts directory. In one of the samples I essentially re-wrote the Lab 6 - syscall-242 sample system calls entirely as modules without modifying the kernel source code. Seems to work just fine.

• Follow the steps in the C Programming Warmup
• Code Samples
• Solutions (See the main OS page or the C support page)

Lab 2 - Nutt Lab 2 - Shell, Due Tuesday Week 4

• Read Nutt pp1-50, 67-82.
• Complete the Nutt lab exercise 2 stated on pp77-82. You only need to complete Part A; we will be doing a more complete shell covering parts B and C later during the spring quarter Unix System Programming and Concurrency.
• Code Samples
• Solutions (See the main OS page or the C support page)

• Read Nutt pp1-50 (again) and pp51-65.
• Complete all parts of the Nutt lab.
• Code Samples

• Read Nutt pp1-50 (again) and pp83-95
• Complete all parts of the Nutt lab.
• Code Samples
• FAQ
  • What Linux OS can I use? You can use any Linux OS that has the C development package installed so you can compile C programs using system calls. This will include the header files that are referred to in the man pages for the system calls you are using. Always use the man pages on the system that you are programming.
  • Do I need the kernel source code? Not to do the programming, but the lab suggests you look at the some of the source code files. If you're just looking at source code files, then you can look on grace or the lab machines or any other linux system with source code because they will all be similar enough for just reading code.
  • Where is the linux source code? Look on page 89 of Nutt to see the layout of the linux source code tree. It will be similar (but not exactly the same) on all linux systems. Take special note of where the include files are. Most of what you need is in include/linux/kernel or else include/asm for machine specific code.

• The Linux Documentation Project Guides
• The Linux Kernel Module Programming Guide
• Lab 5 Code Samples for Slackware2.2VM in VirtualBox
  

• Read Nutt pp1-50 (again) and pp97-105
• Reproduce enough of the sample kernel module code discussed in the Linux Kernel Module Programming Guide (LKMPG) so you can successfully load and register a kernel module function. Note that the code depends on the kernel version you are using.
• Now build a kernel module function to supply a very simple proc file read. You should be able to find this example in the LKMPG also. Note that the code depends on the kernel version you are using.
• Finally, you are ready to build the kernel module described in the Nutt lab to implement a readable proc file clock.

• FAQ
  • What Linux OS can I use? Now you need to use a version of linux that has the kernel source code and you need to have root access so you can compile kernel module code.
  • Do I need the kernel source code? Yes. We have supplied a Slackware 2.2 kernel vdi file that can be used on any machine that runs Sun Microsystem's VirtualBox. This old version of linux best matches the Nutt lab book.
  • Can I use a newer linux kernel? Yes, but you will need to do more research beyond the Nutt text to do your kernel coding. Fortunately for this kernel module code project the LKMPG has sample code that works for the 2.2, 2.4, and 2.6 kernels. Use the 2.4 guide when working with the 2.2 kernel - I believe it has some legacy code for use with the 2.2 kernel.
  • Can I get the code samples in the Nutt book to work? Yes, but not exactly as they are listed in the text. See the sample code listed above to replace what is in the Nutt text. We obtained our sample code from the LKMPG and experimentation.

• Note 2010.01.03 The Slackware2.4 kernel vdi posted in the kernel images handout directory should now work well with this lab using the LKMPG guide for the 2.4 kernel.
• Lab 5 Code Samples for Slackware2.4VM in VirtualBox
  
• The essence of the program you will write is on p103 in the section entitled "Problem Statement". Your kernel module will supply a proc file called clock that when read will return the values of the kernel xtime variable fields for seconds and microseconds. Your test program for your kernel module will be the simple loop at the bootom of p103 and top of p104 that compares the gettimeofday system call time with the kernel time variables that your proc file clock read module returns.
• The final mystery is how the gettimeofday system call can get such fine clock resolution when your reading of the time variables themselves (which are based on the timer interrupts) are not that precise. I think.

• Lab 5 Code Samples for Slackware2.4VM in VirtualBox
  
• The Linux Kernel Module Programming Guide

• The Linux Documentation Project Guides
• The Linux Kernel Module Programming Guide
• Lab 6 Code Samples for Slackware2.4VM in VirtualBox
  

• Read Nutt pp107-118 on System Calls in the Linux 2.2 kernel. What's different about the 2.4 kernel from Nutt's description of the 2.2 kernel? The 2.4 kernel has already defined several new but unimplemented system calls that we can usurp for our own experiments. Thus, the kernel system call table size does not need to be adjusted. Look at the include file angle < asm/unistd.h> and the kernel code file arch/i386/kernel/entry.S. Note: the brackets in < asm/unistd.h> mean you are to assume a /usr/src/linux/include prefix.
• Download and install the Slackware2.4 kernel vdi in virtualbox.
• Boot your new Slackware2.4 kernel from virtualbox.
• Login as root, password is password.
• Read the README files in the /usr/src/linux 2.4 kernel source directory regarding kernel compilation.
• Recompile the Slackware 2.4 kernel according to the instructions in the kernel source directory README and the instructions in the Lab 6 Notes file given in the sample code directory above.
• Copy your new bzImage kernel along with the .config file and the System.map file produced by the compile into your /boot directory.
• Check to see that the size of your new kernel is the same as the size of the original kernel (it should be, because you have just recompiled the same source code and only the date information should change).
• Modify the /etc/lilo.conf file and run /sbin/lilo to add your new kernel to the boot menu. Again, the Lab 6 notes file in the sample code directory summarizes the job.
• Reboot into your new kernel. Of course, it will be the same as the original boot kernel, but now you've built it.

• Now you are ready to do kernel modifications and recompile. You will start by following the sample code for the syscall-240 and just replace that one unused system call with your own code. For now just use the sample code and follow the instructions about what kernel files need to be changed and how you can change the Makefile.
• Recompile your modified kernel and then run your test program to see if your new kernel system call works!
• Now go back and try the syscall-242 modifications that add three new system calls, allowing for some parameter passing and return results.
• Finally, you are ready to pick up the discussion on p110 of the Nutt system call lab and work through the lab.
• The sample programs use syscall. If you want, you can try generating a system call stub and reworking the sample programs. See the discussion on p110. Remember, you're working with the 2.4 kernel and Nutt's discussion applies to the 2.2 kernel, so be on the lookout for changes in the way things are done.
• Read the discussion on pp111-113 about the dangers of writing kernel functions that do not carefully check their parameters.
• Read the discussion on pp113-114 about referencing user-space memory and extend the sample program syscall-242 so it can write back into user space. Again remember that you're working with the 2.4 kernel and Nutt's discussion applies to the 2.2 kernel, so be on the lookout for changes in the way things are done.
• Finally, follow the discussion on pp114-116 about adding your own gettimeofday system call that you'll name pedagogictime.

By the way, it is conceivable and even possible to skip the prototype stage and go straight to kernel programming to solve the problem. In the real world this is guttsy and risky - you might end up with nothing to show for your efforts because the problem was more difficult than you expected. On the other hand, it is also possible that you'll spend all the effort to build a prototype and discover that the kernel programming was very simple after all and maybe you didn't need any prototype code.

Lab 8 - Nutt Lab 8 - Event Queues for Synchronization - Kernel Implementation

• Sample Code for Lab 8