linux内核调试技术手册
3星 · 超过75%的资源 需积分: 16 90 浏览量
2008-09-27
12:29:22
上传
评论 2
收藏 159KB PDF 举报 
Kernel Module Packages Manual
for CODE 10
March 6, 2006
This document specifies the requirements for rpm packages that contain kernel modules, and
describes the processes surrounding those packages including building, signing, installing,
and upgrading. A complete example is given and explained.
This version of the Kernel Module Packages Manual applies to the Novell/SUSE CODE 10
code base, which includes SUSE Linux 10.1, SLES 10 (SUSE Linux Enterprise Server), as
well as all products based on SLES 10. An second version of this document for CODE 9 is
available as well; the CODE 9 version covers SLES 9 and SUSE Linux 10.0.
A few issues related to the new package manager and dependency resolver library still need to
be tested and documented here. The relevant places in this document are highlighted like this
paragraph.
Introduction
The Linux kernel supports adding functionality at runtime through kernel loadable modules.
It includes more than 1500 modules, about 75 percent of which are hardware drivers. These
modules are shipped as part of the kernel packages. In some cases it is desirable to add
additional modules or replace existing ones. (For example, a driver for a particular storage
controller that was not available at the time of product release might be added later in order to
support new hardware.)
Kernel modules interact with the kernel by the means of exported symbols, in a way similar to
how binaries use shared libraries.
1
To ensure that the kernel and modules refer to the same
symbols, a version checksum (aka modversion) is added to each symbol that is computed
from the symbol’s type: in the case of function symbols, the checksum is determined by the
function’s parameters and return type.
When any of a function’s parameters or the return type changes, the checksum changes as
well. This includes all the data types involved recursively: if a function takes a struct
task_struct as parameter and struct task_struct includes a field of type struct dentry, then a
change to struct dentry will cause the symbol’s version checksum to change as well. Symbol
version checksums for different kernel flavors (e.g., kernel-default vs. kernel-smp) will not
match, and symbol versions of the same kernel package on different architectures (e.g.,
kernel-default on i386 vs. x86_64) will not match, either. This mechanism ensures that the
kernel and kernel modules agree on the types of data structures that they use to communicate.
Unless symbol version checking is disabled, modules will only load if the checksums of the
symbols they use match the checksums of the symbols that the kernel exports. The exported
symbols and their version checksums comprise the kernel Application Binary Interface (ABI).
When an update kernel includes kernel ABI changes, kernel modules that use any modified
symbols must be updated as well.
1 The /proc/kallsyms file lists all symbols currently known to the kernel.
剩余10页未读，继续阅读
资源评论
djinglan2012-08-10对了解内核和模块是如何交互的有些用处
