Linux kernel DeviceSimulatorFramework

Article title: Linux kernel DeviceSimulatorFramework entry. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Device Simulator Framework (DSF) provides an easy-to-use input/output control (ioctl) interface for all your devices, whether or not these devices exist. For experienced kernel and device driver software developers, DSF makes debugging and testing device code easier, and it will be hard to simulate and reproduce without DSF.
　　
Creating test cases for the Linux kernel is quite simple; it usually requires either a specific range or a wide range. However, when testing in a user space, there are some special cases that may be difficult to test. It is difficult to test Branch codes, nonexistent devices, and error path codes that are rarely executed.
　　
Device Simulator Framework (DSF) can solve this problem. it has an input/output control interface for kernel space to the user space, allowing test case developers to execute specific target regions of the kernel. DSF is particularly helpful for executing the device driver kernel code when the device may not exist. Although DSF cannot replace real device testing, it can help you debug and test driver code to a great extent.
　　
DSF can also accelerate the development of test cases because you do not have to learn the input/output control interfaces used for user/kernel space communication.
　　
So far, only kernel versions between Linux 2.5.xx and 2.6.xx are supported.
　　
　　 Getting started
First, we recommend that you download the entire Linux Test Project (LTP) Test suite, including the DSF code. Linux Test Project is a Project that IBM Linux Technology Center (LTC) cooperates with other organizations (see the link in references ).
　　
After extracting the archive file, you will find the user/kernel template test code in the testcases/kernel/device-drivers/dev_sim_framework directory. Compile the LTP test suite, install it, and switch to the DSF directory. After entering the DSF directory, you will see the kernel_space directory and the user_space directory. The corresponding kernel modules and user space files are in these two directories respectively. Switch to these two directories and run make to compile the template.
　　
　　 Ioctl request
The ioctl function processes the underlying device parameters of a dedicated file. Specifically, the operation attributes of many character-specific files (such as terminals) can be controlled by ioctl requests.
　　
　　 Use Template
After the template is compiled, you can use insmod or modprobe to load the kernel module before executing the user space code. Switch to the user_space directory and run the user space code. Because the template only communicates with the registered kernel module and returns the result, the user code runs and returns the result quickly.
　　
It is relatively easy to modify the template to execute the desired kernel code. However, we still need some kernel programming knowledge. The functions defined in the EXPORT_SYMBOL label are public to all kernel code. you can directly call them in your kernel module without modifying the kernel code. You can also manually modify the kernel source code to export other functions for re-compilation and testing after loading the new kernel.
　　
　　 DSF application
The following code is an example of how to test the device type:
　　
List 1. Virtual device code
Switch (cmd ){
Case LTP_OPTION1: rc = test_option (); break;
Case PCI_ENABLE: rc = pci_enable (); break;
Default:
Printk ("Mismatching ioctl command
");
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
");
Return 1;
}
　　
If (pci_enable_device (dev )){
Printk ("tpci: failed to enable pci device
");
Rc = 1;
}
　　
Else {
Printk ("tpci: enabled pci device
");
Rc = 0;
}
　　
Return rc;
}
　　
This example enables a "virtual" pci device that calls the PCI kernel API. This virtual device can also be used for other tests.
　　
　　 Conclusion
If you are an experienced Linux kernel and device driver developer, using DSF will benefit you both: because DSF templates can be used for many different tests, therefore, you can develop test cases faster and ensure they are more consistent. In addition, you can execute the specific target area of the kernel, so that the typical user space test case will not be aimlessly executed when executing the kernel code.
　　
The objective of the Linux Test Project is to help device driver developers standardize device unit tests and improve the stability of device drivers in the Linux kernel. With this in mind, you are welcome to contact me through mridge@us.ibm.com and share your experience with DSF.