1 / 10

Nutt Exercise IV

Kernel Modules. Nutt Exercise IV. 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

ronli
Download Presentation

Nutt Exercise IV

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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 http://www.faqs.org/docs/kernel/ (older version) http://www.tldp.org/HOWTO/Module-HOWTO/index.html (2003, latest I have found)

More Related