Kernel modules do not get fully linked when built because some of the symbols they refer to do not exist anywhere but in a running kernel. Despite this complication, the FiST translator should check for any possible unresolved symbols and warn the user.
The naive way to find out if a kernel module is referring to nonexistent symbols is to load it and link it with the running kernel. If any problems arise, the system may hang or panic and crash.
The standard way to avoid this problem is to link the module at user level with a library that includes a main() procedure and dummy definitions for all the symbols that a kernel might export.
To write such a library it is necessary to know all the symbols a kernel exports. Older operating systems (such as SunOS 4.x) allow for kernel memory access through a device called /dev/kmem. Through this device a privileged process can ``browse'' the memory of a running kernel to find symbols. The build procedure for newer operating systems (such as FreeBSD 2.1.x) produces a ``kernel library'' (e.g., libkern.a) and header files that include all the symbols one needs.
Following this method, FiST will include an auto-configuration procedure that must be run only once for each operating system version. This procedure will search for all needed kernel symbols and create code to link with file system modules.