221 lines
8.5 KiB
Plaintext
221 lines
8.5 KiB
Plaintext
#
|
|
# 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.
|
|
#
|
|
# $Id: README,v 1.3 1993/11/23 04:48:04 cgd Exp $
|
|
#
|
|
|
|
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 heirarchy
|
|
|
|
This is the build heirarchy 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 developement, this will end up happening (hopefully)
|
|
less frequently than changing, recompiling, installing, and
|
|
rebooting would normally occur. This should speed developement
|
|
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 incompatability 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
|
|
compatability (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
|
|
developement 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
|