1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
Where to keep your modules and how to configure them
====================================================
This text describes the strategy Debian GNU/Linux uses for locating
kernel modules, and handling the configuration for modules.
Copyright 1996,1999 W.Akkerman <wakkerma@debian.org>
1. Configuration
The Linux module utilities use one configuration file for all their
configuration. This makes it hard for packages to dynamically add
information about their own modules. To fix this Debian GNU/Linux
now uses update-modules.
update-modules attempts to fix this by generating the configuration file
from seperate files which are located in /etc/modutils. All files in
that directory are assembled together to form /etc/conf.modules. There
is also a special subdirectory (/etc/modutils/arch) which contains
information for special architectures. For m68k we also support
subarchitectures to differntiate atari, amiga and mac system.
At runtime update-modules determines the architecture and selects which
file it must use.
There are two types of file you can put in /etc/modutils: normal files
and exectuable files. Normal files contain standard modules
configuration information, as described in the manpage for modprobe.
Executable files are executed and their output is used as extra
configuration information.
2. Different types of modules
The first thing to notice is that we have to kinds of modules:
- modules that are specific to one kernel version. These modules are
included with the kernel source and evolve along with the kernel.
- somewhat more `general' version. These modules are not updated with
every new kernel. However, since the module-kernel interface or
kernel internals mature over time they do need to be changed on
occasion.
3. Where do we keep module-directories?
In order to make use of these two module type we use two locations for
storing them. The current filesystem standard (latest revision 1.2) only
states that kernel loadable modules should be in /lib/modules but leaves
us free otherwise.
Following kernel development every Linux system uses /lib/modules/`uname -r`/
(where `uname -r` gives the current kernel revision) for normal modules. This
gives /lib/modules/2.0.23, /lib/modules/2.1.3, etcetera.
As said before, some modules do not have to be updated with each new kernel.
They can remain the same for a while series of kernels. To support this we use
one module-directory for a whole version. This gives /lib/modules/2.0,
/lib/modules/2.1, etcetera.
Here is a sample directory structure:
/lib/modules -- Main directory for modules
|
+-2.0 -- modules for 2.0.xx kernels
+-2.0.20 -- modules specific for kernel 2.0.20
+-2.0.23 -- modules specific for kernel 2.0.23
+-2.1 -- modules for 2.1.xx kernels
+-2.1.3 -- modules specific for kernel 2.1.3
+-2.1.5 -- modules specific for kernel 2.1.5
3. Internal structure of a module-directory.
To make maintaining modules easier each module-directory has an internal
structure that makes it easier for us to locate a module: each type of
module has a seperate subdirectory allocated for it. Currently we have
xxx different types:
-fs: filesystems. Things like msdos, vfat, nfs and minix.
-net: networking code. For example: slip, ppp, ipx and helpers.
-scsi: SCSI drivers.
-block: drivers for block devices. Examples: ide, loop
-cdrom: drivers for non-IDE cdrom drives
-ipv4: IP version 4 networking code
-ipv6: IP version 6 networking code
-misc: all the other stuff like sound, watchdog, etc.
-nls: national language support, used by DOS and ISO9660 filesystems
-ham: HAM-radio drivers
-sound: Audio drivers
-video: video drivers, framebuffer code
-fc4: fibre channel and FC4 SCSI
Furthermore a module-directory usually contains a modules.dep file, which
tells insmod about module dependencies.
|
