> Manage/Query kernel and kernel modules at runtime
Key files, terms and utilities include:
/lib/modules/kernelversion/modules.dep – Kernel module interdependencies
/etc/modules.conf & /etc/conf.modules – modprobe configuration file (new and old)
Commands | Description
depmod | Determine module dependencies
insmod | Insert a module into the kernel
lsmod | List kernel modules
rmmod | Remove an installed kernel module
modinfo | Show information about a kernel module
modprobe | Install modules and their dependencies (or remove)
uname | Unix name, and kernel version number.
> Kernel Modules
Loadable kernel module was introduced
There are now modules that support the following types of thing (and a whole lot more than this too):
• Filesystems (e.g. ext3, reiserfs, vfat, jfs, xfs)
• Character and block devices (tapes, mice, serial ports, hardware sensors)
• Network adapters from various manufacturers and of various sorts
There are a couple of consequences to the Linux approach to modules:
• Kernel modules are “object files”, exactly like what is produced when compiling a C program.
The linking part of compiling a C program is what happens when a module is loaded.
Somehow, the kernel manages to support unlinking of these linkedin objects too.
• Modules must be compiled with the same options as the kernel they are part of, since they are simply pluggable parts of the same monolithic program.
• Modules from one kernel version will not work with other kernel versions.
• Modules will rely on other parts of the kernel to be present – possibly on other modules (introducing dependencies).
> Inserting modules
To load a single module into the kernel, you use the command insmod. To remove a single module from the running kernel, the command is rmmod.
modinfo displays information about a module.
insmod – accepts a filename (usually ending in .o) or a module name as its argument.
rmmod – will only accept the name of the particular module as its argument.
> modprobe, modules.conf and depmod
It’s like this:
• depmod – examines modules forming part of the kernel, and generates /lib/modules/*/modules.dep, which lists
the full paths of the modules, and also which modules are required to be loaded before a particular module.
• /etc/modules.conf (or /etc/conf.modules in older versions) lists the parameters for modules (e.g. io=0x220 and irq=7)
• modprobe loads a module with the parameters specified in /etc/modules.conf, and also loads all the modules required by that module.
http://youtu.be/PvzKny_TSNM
———————————————————–
> The kernel
The kernel is the core of the operating system. It is the first “process” to start and provides
many of the services required by other software “user land” applications. The kernel facilitates four basic types of services:
1. creation and management of processes
2. the filesystem/s
3. communication with hardware
4. means to start the system
The kernel provides these facilities in two broad functional groups, these are the autonomous
and responsive functions. Examples of autonomous functions are the allocation of memory
and CPU time to processes, undertaken without any special request being directed at the kernel.
The allocation of other system resources, such as the use of hardware, is usual responsive and
the the requesting process never have final control over this resource. All requests against this
resource are still directed through the kernel and the kernel may deny any request from a user
land process.
For example, a process has obtained read access to a file does not read data directly from the disk,
but rather requests the kernel to read the file though a suitable function call.
The kernel only complies with the request after it has determined the validity of the
request. Requests directed to the kernel from processes are often called system calls and the
set of services exposed by the kernel forms the kernel’s application program interface (API).
Here are some examples of system calls.
• fork – fork creates a copy of the parent process that differs only in process ID and parent
process ID. An example of the use of this system call is a web server where the server
forks a copy of itself to deal with each new request.
• exec – exec request the kernel to replace the present process with a new process loaded
from a file. The regular method of starting new processes on Linux is for the parent to fork
and exec.
• kill – The kill system call requests the kernel to send a signal to another process. This is the
system call implemented by the kill command line program.
• open – convert a file name into a file descriptor for reading and writing. Before any file is
read or written, it is “opened”.
• read – read data from a file descriptor.
• write – write data to a file descriptor.
• close – close an open file descriptor.
• exit – terminates the current process.
The system call interface acts as an abstraction of the hardware, such that, a process does not
need to know the specifics of the hardware on which it is running or how that hardware has
been configured. An example of this is that all network devices look the same to a process
irrespective of the underlying hardware. Similarly, all files look the same to processes,
irrespective of the underlying filesystem.
The kernel configures the CPU to provide insulation between processes, so that processes do
not interfere with each other. It is expected of a well designed and implemented kernel that
even delinquent processes will not excessively interfere with the correct functioning of other
processes.
System Administrator