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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
This file describes the strategy for dynamically loadable modules
in the Linux kernel. This is not a technical description on
the internals of module, but mostly a sample of how to compile
and use modules.
Note: You should ensure that the modutils-X.Y.Z.tar.gz you are using
is the most up to date one for this kernel. The "X.Y.Z" will reflect
the kernel version at the time of the release of the modules package.
Some older modules packages aren't aware of some of the newer modular
features that the kernel now supports. The current required version
is listed in the file linux/Documentation/Changes.
* * * NOTE * * *
The kernel has been changed to remove kerneld support and use
the new kmod support. Keep this in mind when reading this file. Kmod
does the exact same thing as kerneld, but doesn't require an external
program (see Documentation/kmod.txt)
In the beginning...
-------------------
Anyway, your first step is to compile the kernel, as explained in the
file linux/README. It generally goes like:
make config
make dep
make clean
make zImage or make zlilo
In "make config", you select what you want to include in the "resident"
kernel and what features you want to have available as loadable modules.
You will generally select the minimal resident set that is needed to boot:
The filesystem of your root partition
A scsi driver, but see below for a list of SCSI modules!
Normal hard drive support
Net support (CONFIG_NET)
TCP/IP support (CONFIG_INET), but no drivers!
plus those things that you just can't live without...
The set of modules is constantly increasing, and you will be able to select
the option "m" in "make config" for those features that the current kernel
can offer as loadable modules.
You also have a possibility to create modules that are less dependent on
the kernel version. This option can be selected during "make config", by
enabling CONFIG_MODVERSIONS, and is most useful on "stable" kernel versions,
such as the kernels from the 1.2 and 2.0 series.
If you have modules that are based on sources that are not included in
the official kernel sources, you will certainly like this option...
Here is a sample of the available modules included in the kernel sources:
Most filesystems: minix, msdos, umsdos, sysv, isofs, hpfs,
smbfs, nfs
Mid-level SCSI support (required by top and low level scsi drivers).
Most low-level SCSI drivers: (i.e. aha1542, in2000)
All SCSI high-level drivers: disk, tape, cdrom, generic.
Most Ethernet drivers: (too many to list, please see the file
./Documentation/networking/net-modules.txt)
Most CDROM drivers:
aztcd: Aztech,Orchid,Okano,Wearnes
cm206: Philips/LMS CM206
gscd: Goldstar GCDR-420
mcd, mcdx: Mitsumi LU005, FX001
optcd: Optics Storage Dolphin 8000AT
sjcd: Sanyo CDR-H94A
sbpcd: Matsushita/Panasonic CR52x, CR56x, CD200,
Longshine LCS-7260, TEAC CD-55A
sonycd535: Sony CDU-531/535, CDU-510/515
And a lot of misc modules, such as:
lp: line printer
binfmt_elf: elf loader
binfmt_java: java loader
isp16: cdrom interface
serial: the serial (tty) interface
When you have made the kernel, you create the modules by doing:
make modules
This will compile all modules and update the linux/modules directory.
In this directory you will then find a bunch of symbolic links,
pointing to the various object files in the kernel tree.
Now, after you have created all your modules, you should also do:
make modules_install
This will copy all newly made modules into subdirectories under
"/lib/modules/kernel_release/", where "kernel_release" is something
like 2.0.1, or whatever the current kernel version is...
As soon as you have rebooted the newly made kernel, you can install
and remove modules at will with the utilities: "insmod" and "rmmod".
After reading the man-page for insmod, you will also know how easy
it is to configure a module when you do "insmod" (hint: symbol=value).
Nifty features:
---------------
You also have access to two utilities: "modprobe" and "depmod", where
modprobe is a "wrapper" for (or extension to) "insmod".
These utilities use (and maintain) a set of files that describe all the
modules that are available for the current kernel in the /lib/modules
hierarchy as well as their interdependencies.
Using the modprobe utility, you can load any module like this:
/sbin/modprobe module
without paying much attention to which kernel you are running, or what
other modules this module depends on.
With the help of the modprobe configuration file: "/etc/modules.conf"
you can tune the behaviour of modprobe in many ways, including an
automatic setting of insmod options for each module.
And, yes, there _are_ man-pages for all this...
To use modprobe successfully, you generally place the following
command in your /etc/rc.d/rc.S script. (Read more about this in the
"rc.hints" file in the module utilities package, "modutils-x.y.z.tar.gz".)
/sbin/depmod -a
This computes the dependencies between the different modules.
Then if you do, for example
/sbin/modprobe umsdos
you will automatically load _both_ the msdos and umsdos modules,
since umsdos runs piggyback on msdos.
Using modinfo:
--------------
Sometimes you need to know what parameters are accepted by a
module or you've found a bug and want to contact the maintainer.
Then modinfo comes in very handy.
Every module (normally) contains the author/maintainer,
a description and a list of parameters.
For example "modinfo -a eepro100" will return:
Maintainer: Andrey V. Savochkin <saw@saw.sw.com.sg>
and "modinfo -d eepro100" will return a description:
Intel i82557/i82558 PCI EtherExpressPro driver
and more important "modinfo -p eepro100" will return this list:
debug int
options int array (min = 1, max = 8)
full_duplex int array (min = 1, max = 8)
congenb int
txfifo int
rxfifo int
txdmacount int
rxdmacount int
rx_copybreak int
max_interrupt_work int
multicast_filter_limit int
The "ultimate" utility:
-----------------------
OK, you have read all of the above, and feel amply impressed...
Now, we tell you to forget all about how to install and remove
loadable modules...
With the kerneld daemon, all of these chores will be taken care of
automatically. Just answer "Y" to CONFIG_KERNELD in "make config",
and make sure that /sbin/kerneld is started as soon as possible
after boot and that "/sbin/depmod -a" has been executed for the
current kernel. (Read more about this in the module utilities package.)
Whenever a program wants the kernel to use a feature that is only
available as a loadable module, and if the kernel hasn't got the
module installed yet, the kernel will ask the kerneld daemon to take
care of the situation and make the best of it.
This is what happens:
- The kernel notices that a feature is requested that is not
resident in the kernel.
- The kernel sends a message to kerneld, with a symbolic
description of the requested feature.
- The kerneld daemon asks e.g. modprobe to load a module that
fits this symbolic description.
- modprobe looks into its internal "alias" translation table
to see if there is a match. This table can be reconfigured
and expanded by having "alias" lines in "/etc/modules.conf".
- insmod is then asked to insert the module(s) that modprobe
has decided that the kernel needs. Every module will be
configured according to the "options" lines in "/etc/modules.conf".
- modprobe exits and kerneld tells the kernel that the request
succeeded (or failed...)
- The kernel uses the freshly installed feature just as if it
had been configured into the kernel as a "resident" part.
The icing of the cake is that when an automatically installed module
has been unused for a period of time (usually 1 minute), the module
will be automatically removed from the kernel as well.
This makes the kernel use the minimal amount of memory at any given time,
making it available for more productive use than as just a placeholder for
unused code.
Actually, this is only a side-effect from the _real_ benefit of kerneld:
You only have to create a minimal kernel, that is more or less independent
of the actual hardware setup. The setup of the "virtual" kernel is
instead controlled by a configuration file as well as the actual usage
pattern of the current machine and its kernel.
This should be good news for maintainers of multiple machines as well as
for maintainers of distributions.
To use kerneld with the least amount of "hassle", you need modprobe from
a release that can be considered "recent" w.r.t. your kernel, and also
a configuration file for modprobe ("/etc/modules.conf").
Since modprobe already knows about most modules, the minimal configuration
file could look something like this:
alias scsi_hostadapter aha1542 # or whatever SCSI adapter you have
alias eth0 3c509 # or whatever net adapter you have
# you might need an "options" line for some net adapters:
options 3c509 io=0x300 irq=10
# you might also need an "options" line for some other module:
options cdu31a cdu31a_port=0x1f88 sony_pas_init=1
You could add these lines as well, but they are only "cosmetic":
alias net-pf-3 off # no ax25 module available (yet)
alias net-pf-4 off # if you don't use the ipx module
alias net-pf-5 off # if you don't use the appletalk module
Written by:
Jacques Gelinas <jacques@solucorp.qc.ca>
Bjorn Ekwall <bj0rn@blox.se>
|
