Session 3 - Introduction to Kernel Space and API

Tasks

Download and unzip the tasks archive sesiune-03 on the virtual machine.

  1. Syscalls
    • Follow the code in 1-syscall directory.
    • my_syscall.c implements a module that adds a custom syscall on position 0 in the syscall table.
      • Note: In the later kernel version, the syscall table cannot be accessed from modules (is not exported) but our kernel was modified in order to export it.
    • Our custom syscall implements the hostname syscall by changing the name of the caller's machine.
    • my_hostname.c implements the userspace part (caller) of our syscall.
    • In order to test it, run the following commands:
      root@spook:~/1-syscall# make //generates the module
      root@spook:~/1-syscall# insmod my_syscall.ko //insert module
      root@spook:~/1-syscall# lsmod //check if the module was inserted
       
      root@spook:~/1-syscall# make my_hostname //generates the userspace syscall caller
      root@spook:~/1-syscall# ./my_hostname happy //changes the hostname to "happy"
       
      root@spook:~/1-syscall# dmesg //to follow the printk log messages
    • Since the function that notifies the userspace that the hostname has changed wasn't exported for modules, you'll have to log in again or call hostname in order to verify the changes.
    • Do you notice any problem with my_syscall's implementation? What happens if the user provides an invalid pointer through name parameter? Run ./my_hostname without parameters in order to send a NULL pointer as the desired hostname.
    • Correct the encountered problem and run ./my_hostname again.
  2. Proc Filesystem
    • The module implemented in 2-procfs directory can be used in order to export kernel information to user space through /proc pseudo-filesystem.
    • Compile and load the module. Look for /proc/myproc/fis file.
    • Implement the TODO by printing the pid of the current process in the proc file.
      • Hint: the current process is defined as a global macro named current.
    • Include any additional header if the module doesn't compile.
    • Follow the code and notice how the proc pseudo-filesystem can be managed from the kernel. It also supports write operations.
    • In order to test it, run the following commands after loading the module:
      root@spook:~/2-procfs# cat /proc/myproc/fis &
    • By running the command in background it also returns the pid of the cat command. If your implementation is correct, this value would correspond to the one read from /proc/myproc/fis file (the pid of the current process).
    • You can also use dmesg to follow the printk logs.
  3. Seq Operations
    • The module in 3-seq also writes information in /proc filesystem, but this time it uses some special operations in order to update the information in “sequences”. Follow the comments in the code in order to understand this operations that are triggered each time the associated proc file is read.
    • Notice that this module can also receive parameters on insert/load, that are retrieved using module_param function. Basically the function defines expected parameters by their name and type. So, in order to load this module with an integer as a parameter we would run insmod mseq.ko mypid=123.
    • The module implements the following “features”, that are updated on each read of the proc file:
      • Keeps a counter variable that is incremented on each read in order to simulate a timer.
      • It has to print information (pid, command name, nice value) about the process (task) that has the same pid as the value of the module's parameter.
    • You have to implement the TODO by printing the (pid, command name, nice value) of the selected task.
    • After that, we can simulate our little top program by following the steps below:
      • Open a second terminal and start a htop process in it.
      • In the first terminal load the module insmod mseq.ko mypid=123 and dynamically monitor the proc file watch -n 1 cat /proc/mytop.
      • As a parameter pid in insmod you can send the htop's pid (that runs in the second terminal).
      • You can see how the timer is incremented on each read (at every 1 second as was set to watch).
      • Now go in the second terminal, and play with the htop's nice value by incrementing and decrementing it. You can notice how this value is also updated in our simulated top, the watch in the first terminal.
sesiuni/kernel/api.txt · Last modified: 2012/07/04 09:54 by laurag