Nutt Exercise IV - PowerPoint PPT Presentation

kernel modules n.
Skip this Video
Loading SlideShow in 5 Seconds..
Nutt Exercise IV PowerPoint Presentation
Download Presentation
Nutt Exercise IV

play fullscreen
1 / 10
Download Presentation
Nutt Exercise IV
Download Presentation

Nutt Exercise IV

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Kernel Modules Nutt Exercise IV

  2. Linux Kernel Modules • A Linux Kernel Module is a set of functions and data types that can be compiled as an independent program • Compilation needs appropriate flags to indicate that it is kernel code • Linux modules are then linked, or installed, into the kernel. • To see what modules have been installed, read the pseudofile /proc/modules • Installation can be done in 2 different ways • Static loading – done when kernel is started • Dynamic loading – done while kernel is running (insmod and rmmod commands)

  3. Use of modules • Modules can be used for many things • However, they are typically used as device drivers • Note that device drivers need not be modules. They can be a part of the monolithic kernel

  4. Module organization • Once installed, a module executes in supervisor mode in the kernel’s address space • This is different from a module in a microkernel OS, which runs in user mode • Thus a Linux kernel module can read/write kernel data structures, but only if it knows the addresses. • Since modules are designed and implemented independently of the kernel, they can’t reference kernel data structures by variable names by relying on static linking. • The kernel must export symbols for a module to be able to see them • This is done by means of the macro EXPORT_SYMBOL • See the files ksyms.c • Each module can also export its own symbols for modules installed later to see.

  5. A module is almost an object! • A module is treated as a dynamic data type that has an interface that can be interpreted by the static kernel • The minimum module interface includes 2 functions • init_module( ), called by kernel when module is installed, much like an object’s constructor • cleanup_module( ), called by kernel when module is removed, much like an object’s destructor • You can write these 2 functions to do anything you wish • A module can have more than just these functions, of course

  6. Example of a module skeleton #include <linux/kernel.h> #include <linux/module.h> … int init_module( ) { /* runs when module is just installed */ } void cleanup_module( ){ /* runs when module is removed */ }

  7. Telling kernel of module functions other than init_module() and cleanup_module() • To do this, we must register each new function • Registration is usually done in init_module() • Unregistration is usually done in cleanup_module() • Two type of interfaces are available: /proc file system and device driver. We’ll only study the /proc interface. The other one comes later in this book. • When module uses /proc interface the implementation file is saved in /proc directory • Registration and unregistration of module is done via kernel functions proc_register() and proc_unregister • These functions reference a struct proc_dir_entry defined in include/linux/proc_fs.h • This struct specifies the characteristics of the pseudofile that will appear in /proc after module registration

  8. What happens when you read the /proc file • When you read the /proc file corresponding to your new module, you’d like something useful printed on the terminal • To do this, code up the get_info function • Specify it to the kernel in the get_info field of struct proc_dir_entry • The module’s get_info function has a special prototype, which is of the following form: get_info( char *sys_buffer, char **my_buffer, off_t file_pos, int my_buffer_length, int zero ); space for pseudofile space to return info (hence the **) usually unused unused • See code fragment to register and unregister a module named my_module in book, P. 101. Also on the computer.

  9. Module installation and removal • Module is compiled in user space with appropriate flags. • This results in executable file • Install using insmod (/sbin/insmod modulename) The following will now happen: • Add new module to kernel address space via kernel function create_module() • Another kernel function, get_kernel_syms(), resolves ext sym refs in the module, whether refs to syms in kernel or in previously loaded modules • Create_module() allocates mem space for module • Module is loaded by init_module() syscall. Syms defined by this module is exported for modules that come later • insmod calls init_module() function of the newly-loaded module.

  10. On-line book on kernel modules (older version) (2003, latest I have found)