asf(8) [freebsd man page]

ASF(8)							    BSD System Manager's Manual 						    ASF(8)

NAME

     asf -- add symbol files

SYNOPSIS

     asf [-afKksVx] [-M core] [-N system] [-o outfile] [-X suffix] [modules-path [outfile]]

DESCRIPTION

     By default, asf reads kldstat(8) output from standard input and writes to the .asf file a list of gdb(1) commands to add symbol files from
     KLDs in subdirectories of the subdirectory modules of the current directory, which is intended to be a kernel build directory.  This allows
     gdb(1) to load the symbols into the debugging environment.

     An optional modules-path argument can specify a semicolon-separated list of directory pathnames similar to the kern.module_path sysctl.  Each
     directory in the list will be searched in turn for modules.  The default list consists of just one element, modules, which is suitable if the
     current directory is a kernel build directory.

     If outfile is specified, asf writes to it instead of .asf.  If outfile is a single dash ('-'), standard output is used.

OPTIONS

     The following options modify the function of asf:

     -a      When writing to an explicit outfile, append to the file rather than overwriting it.

     -f      Instead of trying to simplistically guess the path for each module, perform a traversal in the same way that find(1) does to locate
	     an exact path for each module, no matter where in modules-path it is located.

     -K      Instead of reading from standard input, use the conventional system interface to get the list of modules currently loaded.

     -k      Instead of reading from standard input, start a kldstat(8) and read the information from it.

     -M      Specify the core file for kvm(3).	Implies -V.

     -N      Specify the system file for kvm(3).  Implies -V.

     -o      Specify the file for asf to write or append its output to.  If outfile is a single dash ('-'), standard output is used.

     -s      Do not prepend a (guessed) subdirectory of the module path.

     -V      Instead of reading from standard input, use the kvm(3) interface to get the list of modules.  This interface allows for inspecting
	     system crash dumps, as well as the live system.  The -M and -N options will be of use if inspecting a crash dump.	Elevated privi-
	     leges, e.g., those of a superuser, may be needed to use this option.

     -X      Add suffix to the list of suffixes asf tries to append to KLD file names.	The default list consists of .debug, .symbols, and the
	     null suffix.  The null suffix always stays at the list tail, after the suffix added.  Should it be needed in the middle of the list,
	     a blank suffix can be specified to -X instead.

     -x      Clear the list of suffixes asf tries to append to KLD file names.	Only the null suffix is left in the list.

EXAMPLES

     To add symbol files from the system search path specified by the kern.module_path sysctl, the following command can be used:

	   asf -s `sysctl -n kern.module_path`

SEE ALSO

     gdb(1), kvm(3), kld(4), kldstat(8), sysctl(8)

HISTORY

     The asf utility first appeared in FreeBSD 5.2.

AUTHORS

     Greg Lehey <grog@FreeBSD.org>

BUGS

     Module paths are guessed in a rather naive way by default.  It is likely to lag behind the changes to the build tree layout.  Using -f is
     recommended.

BSD
								 December 20, 2006							       BSD

KLD(4)							   BSD Kernel Interfaces Manual 						    KLD(4)

NAME

     kld -- dynamic kernel linker facility

DESCRIPTION

     The LKM (Loadable Kernel Modules) facility has been deprecated in FreeBSD 3.0 and above in favor of the kld interface.  This interface, like
     its predecessor, allows the system administrator to dynamically add and remove functionality from a running system.  This ability also helps
     software developers to develop new parts of the kernel without constantly rebooting to test their changes.

     Various types of modules can be loaded into the system.  There are several defined module types, listed below, which can be added to the sys-
     tem in a predefined way.  In addition, there is a generic type, for which the module itself handles loading and unloading.

     The FreeBSD system makes extensive use of loadable kernel modules, and provides loadable versions of most file systems, the NFS client and
     server, all the screen-savers, and the iBCS2 and Linux emulators.	kld modules are placed by default in the /boot/kernel directory along with
     their matching kernel.

     The kld interface is used through the kldload(8), kldunload(8) and kldstat(8) programs.

     The kldload(8) program can load either a.out(5) or ELF formatted loadable modules.  The kldunload(8) program unloads any given loaded module,
     if no other module is dependent upon the given module.  The kldstat(8) program is used to check the status of the modules currently loaded
     into the system.

     Kernel modules may only be loaded or unloaded if the system security level kern.securelevel is less than one.

MODULE TYPES

     Device Driver modules
     New block and character device drivers may be loaded into the system with kld.  Device nodes for the loaded drivers are automatically created
     when a module is loaded and destroyed when it is unloaded by devfs(5).  You can specify userland programs that will run when new devices
     become available as a result of loading modules, or existing devices go away when modules are unloaded, by configuring devd(8).

FILES

     /boot/kernel		directory containing module binaries built for the kernel also residing in the directory.
     /usr/include/sys/module.h	file containing definitions required to compile a kld module
     /usr/share/examples/kld	example source code implementing a sample kld module

SEE ALSO

     kldfind(2), kldfirstmod(2), kldload(2), kldnext(2), kldstat(2), kldunload(2), devfs(5), devd(8), kldload(8), kldstat(8), kldunload(8),
     sysctl(8)

HISTORY

     The kld facility appeared in FreeBSD 3.0 and was designed as a replacement for the lkm facility, which was similar in functionality to the
     loadable kernel modules facility provided by SunOS 4.1.3.

AUTHORS

     The kld facility was originally implemented by Doug Rabson <dfr@FreeBSD.org>.

BUGS

     If a module B, is dependent on another module A, but is not compiled with module A as a dependency, then kldload(8) fails to load module B,
     even if module A is already present in the system.

     If multiple modules are dependent on module A, and are compiled with module A as a dependency, then kldload(8) loads an instance of module A
     when any of the modules are loaded.

     If a custom entry point is used for a module, and the module is compiled as an 'ELF' binary, then kldload(8) fails to execute the entry
     point.

     kldload(8) returns the cryptic message 'ENOEXEC (Exec format error)' for any error encountered while loading a module.

     When system internal interfaces change, old modules often cannot detect this, and such modules when loaded will often cause crashes or myste-
     rious failures.

BSD
								 November 8, 1998							       BSD