NetBSD/share/lkm

#
# 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.
#
#	$NetBSD: README,v 1.4 1997/10/13 11:20:02 lukem 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