Creating test cases for the Linux kernel is pretty straightforward; usually either very specific or very broad coverage is desired. When testing in userspace, however, it can be very difficult to test for special conditions. Things like branch code that is seldom executed, non-existent devices, and error path code are hard to test.

The Device Simulator Framework (DSF) addresses this problem area, with a kernelspace-to-userspace ioctl interface that allows the test case developer to execute specific targeted areas of the kernel. DSF is especially helpful in executing device driver kernel code where the device may not be present. While DSF is not a replacement for actual device testing, it can greatly assist you in debugging and testing driver code.

DSF can also speed test case development, since you aren't forced to learn the ioctl interface for user/kernel space communication.

Currently, only the later release Linux 2.5.xx through the current 2.6.xx kernels are supported.

Getting started

To begin, I recommend that you download the entire Linux Test Project (LTP) test suite, which includes the DSF code. The Linux Test Project is a joint project with IBM's Linux Technology Center (LTC) and several other organizations (see Resources for a link).

After you extract the archive, you will find the user/kernel template test code in the testcases/kernel/device-drivers/dev_sim_framework directory. Build the LTP test suite and install it, and then change into the DSF directory. Once in the DSF directory, you will see both kernel_space and user_space directories. The respective kernel module and user space files reside in these directories. Change into these directories and run make to build the templates.

Back to top

Using the templates

Once you build the templates, you can load the kernel module with insmod or modprobe prior to executing the userspace code. Change into the user_space directory and execute the userspace code. The user code will run and return very quickly since the template simply communicates with the registered kernel module and returns.

Modifying the template to execute the desired kernel code is relatively straightforward. However, some knowledge of kernel programming is required. The functions defined within the EXPORT_SYMBOL tags are open to all kernel code and can be called directly from your kernel modules without kernel code modification. You can also manually modify the kernel source to export additional functions for test after rebuilding and rebooting the new kernel.

Back to top

DSF in use

The following code is an example of how to implement a device type test:

   switch(cmd) {
     case LTP_OPTION1: rc = test_option(); break;
     case PCI_ENABLE:  rc = pci_enable(); break;
     default:
      printk("Mismatching ioctl command\n");
                           break;
           }

   .
   .
   .

   /*
   * pci_enable
   *  enable a pci device so that it may be used in
   *  later testing in the user test program
   */

   static int pci_enable() {
   int rc = 0;
   struct pci_dev *dev = ltp_pci.dev;

   /* check if can enable the device pointer */
   if(!dev) {
     printk("tpci: dev is NULL\n");
     return 1;
   }

   if( pci_enable_device(dev) ) {
     printk("tpci: failed to enable pci device\n");
     rc = 1;
   }

   else {
     printk("tpci: enabled pci device\n");
     rc = 0;
   }

   return rc;
   }

This example enables a "dummy" PCI device that calls the pci kernel APIs. The dummy device can also be used for other tests.

Back to top

Summary

If you are a Linux kernel and device driver developer with a moderate level of experience, the benefit of using the DSF template is twofold: You can develop test cases faster and more consistently since the DSF template can be used for many different tests. Also, you can target specific areas of the kernel for execution, which eliminates the typical userspace test case hit-or-miss approach to executing kernel code.

The goal of the Linux Test Project is to help device driver developers standardize device unit tests and increase device driver stability in the Linux kernel. With that in mind, please do feel free to contact me at mridge@us.ibm.com with your experiences using DSF, or to participate in the LTP mailing list (see Resources for a link).

Resources

• The Linux Test Project (LTP) is a joint project between IBM's Linux Technology Center and several industry partners.
  
  
• You can post questions or comments about DSF or other aspects of the Linux Test Project suite at the LTP general mailing list.
  
  
• The IBM Linux Technology Center last year put the 2.4 kernel through a comprehensive benchmarking ordeal. Read the results of their efforts in Putting Linux reliability to the test (developerWorks, December 2003).
  
  
• The IBM Linux Technology Center's Paul Larson takes a look behind the scenes at the tools and tests that went into the making of the 2.6 kernel in Improvements in kernel development from 2.4 to 2.6 (developerWorks, February 2004).
  
  
• The Linux at IBM site features Linux news and information from throughout IBM.
  
  
• You can read many articles about how software testing is done at IBM in the IBM Systems Journal.
  
  
• IBM also offers Performance Management, Testing and Scalability Services.
  
  
• The Linux Kernel Archives is the primary site for the Linux kernel source; it also chronicles and links to a great deal of information from the elementary to the advanced.
  
  
• Find more resources for Linux developers in the developerWorks Linux zone.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Getting started
• Using the templates
• DSF in use
• Summary
• Resources
• About the author
• Comments