# $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