Home | History | Annotate | only in /external/ltp/testcases/kernel/device-drivers/dev_sim_framework
Up to higher level directory
NameDateSize
kernel_space/06-Dec-2017
README06-Dec-20173.8K
user_space/06-Dec-2017

README

      1 author: Sean Ruyle (srruyle (a] us.ibm.com)
      2 
      3 RUNTIME:
      4 To run the test case simply enter the user_space directory, type make
      5 to compile the program, and run ./test_mod in this case, or whatver
      6 you have named your program. However, the test kernel module must be
      7 loaded before the test case can work. If the module is not loaded you
      8 will recieve an error when attempting to open the module.
      9 
     10 Enter the kernel_space directory, and again type make to compile the
     11 module. After successful compilation use the load script to load the
     12 module into the system (./load_tmod.sh). The reason for the script
     13 instead of just using insmod to load the module is to ensure that
     14 there is a correct node in /dev, by parsing /proc/devices to get the
     15 right major number.
     16 
     17 Check that the module has been loaded by using the lsmod command.
     18 You should see ouput similar to this:
     19 
     20 ausag:~ # lsmod
     21 Module                  Size  Used by
     22 tmod                    3812  0
     23 gcov_prof               8292  0
     24 uhci_hcd               51812  0
     25 
     26 
     27 To unload the module use the rmmod command. A module cannot be
     28 unloaded if it is still in use by the system or a program.
     29 
     30 
     31 
     32 
     33 USER SPACE:
     34 Ive tried to abstract user space as much as possible so that if
     35 a new test does not need any additional setup of parameters
     36 before the ioctl call, ki_generic can be used by passing in
     37 the file_descriptor and the ioctl flag corresponding to the
     38 current test.
     39 
     40 Examples have been provided for correct usage of passing in
     41 structures to the ioctl call if they are needed for a given
     42 test. These are fuond at the bottom of tmod_ki.c file.
     43 
     44 If a test does call for a structure to be passed in to
     45 kernel space or a structure to be returned you will need to
     46 setup the tif pointer. Use the examples I just mentioned
     47 and it should be easy. The ioctl call is setup so that it
     48 will check if the values passed in need a copy_from_user
     49 or a copy_to_user before moving on. The tif pointer
     50 allows the kernel space ioctl function to handle all
     51 calls in a similar function without depending on the test
     52 that is to be run, in regards to copy_from_user and
     53 copy_to_user.
     54 
     55 
     56 
     57 
     58 KERNEL SPACE:
     59 I strongly suggest that when creating a Makefile for your
     60 test modules you use the one provided here, and just change
     61 the name of the .o file. Little differences can throw a
     62 compiler off even if you dont see a problem.
     63 
     64 The test functions and the ioctl call, as well as init and
     65 exit functions are located in the tmod.c file. Most of it
     66 should be streamlined so that all you need to do to add a
     67 new test function is add an ioctl flag in tmod.h, a function
     68 prototype, a new case in the ioctl switch, and the actual
     69 function itself.
     70 
     71 Two header files are needed in kernel space so that we may
     72 seperate what can be used in user space programs from
     73 what can only be used in kernel space. I put my #defines
     74 and ioctl flags in tmod.h, along with the tif structure.
     75 This is because all of these will need to be used by both
     76 the user space program as well as the kernel module.
     77 
     78 Any extern definitions from the kernel or structures that
     79 will have pointers in them that will differ in user space,
     80 should go in another header file. I used str_mod.h for this,
     81 and for example in my pci testcase, I need a struct pci_dev *
     82 for most of my tests, along with several other pointers.
     83 This structure will allow you to hold the pointers from one
     84 test to another without having to use copy_to_user to
     85 return the pointers to user space program.
     86 
     87 
     88 
     89 
     90 
     91 
     92 On naming:
     93 For this example I just called everything tmod (short for test_mod),
     94 so if you are using these files as a base for your testcases, make
     95 sure that you change tmod and other such inferences, so that it
     96 will be easier to tell in the kernel which module is performing
     97 which action.
     98 
     99 
    100 
    101 
    102 
    103 
    104 Hope this helps. Send me an email if you have any problems
    105 Thanks and gigem,
    106 Sean Ruyle
    107 
    108 srruyle (a] us.ibm.com
    109 
    110 
    111 
    112 
    113 
    114 
    115 
    116 
    117 
    118