Page 256 - DCAP403_Operating System
P. 256

Unit 13: Case Study: Linux




          Let us revisit the working of the insmod to get a clear picture of the module loading operation.   Notes
          The insmod depends on some critical system calls to load the module to the kernel. It uses the
          sys_create_module to allocate kernel memory to hold module. It uses get_kernel_syms system
          call to get the kernel symbol table in order to link the module. It then calls the sys_init_module
          system call to copy the relocatable object code of the module to the kernel space. And soon after
          this, insmod calls the initialization function of the concerned module i.e. init_module. All of these
          system calls can be found in kernel/module.c.

          13.2.3 Unloading Modules

          The modules can be unloaded using rmmod command. While removing modules, rmmod ensures
          the restriction that the modules are not in use and they are not referred by any other module or
          the part of the kernel. The demand loaded modules (i.e. the modules loaded by kerneld) are
          automatically removed from the system by `kerneld’ when they are no longer used. Every time
          it’s idle, timer expires and kerneld makes a system call requesting for all the demand loaded

          kernels, which are not busy to be removed. The modules, whose visited flags are cleared and
          marked as AUTOCLEAN, are `unloaded’.
          Assuming that the module can be unloaded, the cleanup_module function of the concerned
          module is called to freeup the kernel resources it has allocated. After the successful execution of
          the cleanup_module, the module datastructure is marked DELETED and it is unlinked from the
          kernel and unlisted from the list of kernel modules. The reference list of the modules on which
          it (module removed) is dependent is modified and dependency is released. The kernel memory

          allocated to the concerned module is deallocated and returned to the kernel memory spool.
          Version Dependency of modules Version dependency of the module is one of the trickiest parts
          of the Linux Kernel Module programming. Typically, the modules are required to be compiled
          for each version of the kernel. Each module defines a symbol called kernel_version, which

          insmod matches against the version number of the current kernel. The kernel 2.2.x/2.4.x defi ne
          the symbol in. Hence if the module is made up of multiple source files, should be included in

          only one of the source fi les.
          Though typically, modules should be recompiled for each kernel version, it is not always possible
          to recompile module when it is run on as a commercial module distributed in binary form. Kernel
          developers have provided a flexible way to deal with the version problem. The idea is that a

          module is incompatible with a different kernel version only if the software interface offered by
          the kernel is changed. The software interface is represented by the function prototype and the

          exact definition of all the data structures involved in the function call. The CRC algorithm can be
          used to map all the information about software interface to the single 32bit number. The issue of
          version dependency is handled by using the name of the each symbol exported.

          13.3 Process Management

          Any application that runs on a Linux system is assigned a process ID or PID. This is a numerical
          representation of the instance of the application on the system. In most situations this information
          is only relevant to the system administrator who may have to debug or terminate processes by
          referencing the PID. Process Management is the series of tasks a System Administrator completes
          to monitor, manage, and maintain instances of running applications.

          Multitasking

          Process Management beings with an understanding concept of Multitasking. Linux is what is
          referred to as a preemptive multitasking operating system. Preemptive multitasking systems rely
          on a scheduler. The function of the scheduler is to control the process that is currently using the
          CPU. In contrast, symmetric multitasking systems such as Windows 3.1 relied on each running
          process to voluntary relinquish control of the processor. If an application in this system hung or



                                           LOVELY PROFESSIONAL UNIVERSITY                                   249
   251   252   253   254   255   256   257   258   259   260   261