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
|
# $OpenBSD: README,v 1.4 2003/03/06 04:19:45 david Exp $
#
# Copyright (c) 1993 Terrence R. Lambert.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. All advertising materials mentioning features or use of this software
# must display the following acknowledgement:
# This product includes software developed by Terrence R. Lambert.
# 4. The name Terrence R. Lambert may not be used to endorse or promote
# products derived from this software without specific prior written
# permission.
#
# THIS SOFTWARE IS PROVIDED BY TERRENCE R. LAMBERT ``AS IS'' AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE TERRENCE R. LAMBERT BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
#
0.0 README
README file for the loadable kernel modules interface.
Direct questions and comments to:
Terry Lambert
terry@cs.weber.edu
Please do *not* mail me at Novell.
1.0 About this build hierarchy
This is the build hierarchy for the loadable kernel modules
(lkm) command line interface and test suite (including a
set of sample code for each possible module type).
The procedures in this file assume you have installed the
kernel portions of the lkm system and have rebooted your
machine so that they are ready for use.
If you have not done this, then there is no reason for you to
continue; please take the time to install the lkm system into
your kernel at this time.
2.0 Compiler warnings
Some compiler warnings will occur due to inclusion of kernel
and non-kernel header files in the same program that have had
the same function names ANSIfied and the prototypes for the
kernel and libc functions conflict. This needs to be resolved
by fixing the header files, which I haven't bothered to do (the
main conflict was "printf", and I made a dirty hack to get
around it until the header files have been fixed).
3.0 Usage warnings
Loading a bogus module will kill your machine, but if you are
doing development, this will end up happening (hopefully)
less frequently than changing, recompiling, installing, and
rebooting would normally occur. This should speed development
considerably for a lot of the in-kernel work that is currently
taking place.
4.0 Loadable module types supported
There are 6 loadable modules types supported; 5 of these are
specific module types; the sixth is to allow the user to make
their own loader as part of the module and allow them to replace
or extend apropriate tables in the kernel.
4.1 System call modules
System calls as loadable modules use one of two approaches.
If the system call slot is unspecified (-1), it will attempt
to locate (and allocate) the next free call slot that points
to the address of the "lkmnosys" function (an alias for the
"nosys" function). It replaces this with the user's call;
the user can tell which slot was allocated using the "modstat"
command (the call slot is indicated by the value of "Off").
If the system call slot is specified, it will replace that
specific call (assuming it is in range of the entries in the
sysent[] table). Care should be taken when replacing system
calls. Good candiates are calls which the user is attempting
to repair or make POSIX compliant. It is possible to replace
all calls, although care should be taken with the "ioctl()"
call, as it is the interface for the lkm loader.
When unloaded, the system call module replaces the previous
contents of the call slot it was loaded in. If this was an
allocable slot, it is now reallocable; if it was a particular
call slot, the previous function is restored.
The directory ./sample/syscall contains a sample implementation
of a loadable system call.
4.2 Virtual file system modules
A virtual file system can be loaded as a module. The example
provided is for the "kernfs" file system; this is the code in
NetBSD's /sys/kernfs combined in a single object with another
piece of code giving a module entry point for the file system;
with very little effort, any file system can be set up this way
(although I suggest you leave "ufs" statically linked, since
it is necessary for booting).
The critical section of loading a VFS is to get the entry in
the right slot and mounted.
Because of the dependency on the vfssw[] table index during
the mount, we can't simply mix and match file systems except
in their predefined locations with regard to mount. This
means that there are changes to vfssw[] and mount coming
down the road (which will end up incrementing the lkm version
and introducing an incompatibility as far as file system modules
are converned).
The directory ./sample/vfs contains the sample implementation
of the loadable kernfs vfs.
4.3 Device driver modules
The major issue to deal with when creating device drivers is
insuring the creation of the device node. The current approach
to this is executing a module specific shell script upon a
successful load.
A potentially better soloution is encoding the device name in
the device switch, or, better, providing a functional interface
to the init routine, and then using a "/devices" file system
to export devices to the file system name space. Of course,
the default "/dev" directory would have to be maintained for
compatibility (probably using symbolic links).
This distribution does not contain a loadable device driver
example. A potentially beneficial example could be made of
the "lpa" interruptless printer driver.
4.4 Streams modules
Streams module support has been removed from this release; when
the streams implementation is ready, it wil be restored as a
patch.
Please do not ask me for early availability on my streams
implementation; until I have some non-proprietary modules
to distribute, I'm putting work on it on the back burner
while I finish shared libraries.
4.5 Execution interpreters
Execution interpreters allow loading of programs with magic
numbers other than the default numbers supported by NetBSD.
The reasoning behind this is to effectively allow user space
development of changes in exec format to support, among
other things, shared libraries.
Another portential use requires changing the references to
the "sysent[]" system call table from direct references to
indirect through a pointer in the proc struct. This allows
the execution interpreter to, among other things, support
(statically linked) executables from other environments,
like Xenix, SVR3, SVR4, and Linux.
There is no example of a loadable execution interpreter
provided with this distribution.
4.6 Miscellaneous modules
Miscellaneous modules are modules for which there is not a
current, well defined, or well used interface for extension.
They are provided for extension, and the user is expected to
write their own loader to handle the kernel pointer/table
manipulation to "wire in" their loaded module (and "unwire"
it on uload).
One example of a "miscellaneous module" might be a loader for
card-specific VGA drivers or alternate terminal emualtions in
an appropriately layered console driver.
The table manipulations required are specific to the console
interface, yet a loadable module may be used if code is written
to tell it how to manipulate the interfaces within the internal
console interfaces.
An example of a "miscellaneous module" is provided to show how
to write "miscellaneous modules"; it duplicates the functionality
of the "system call" module type, and is not intended to be
seriously used, as it could interfere with the "system call"
module type. The sample code is located in ./sample/misc.
5.0 END OF DOCUMENT
|
