KLDLOAD(8) BSD System Manager's Manual KLDLOAD(8)NAME
kldload -- load a file into the kernel
SYNOPSIS
kldload [-nqv] file ...
DESCRIPTION
The kldload utility loads file.ko into the kernel using the kernel linker. Note that if multiple modules are specified then an attempt will
be made to load them all, even if some fail. The .ko extension name is not mandatory when loading a given module using kldload. It does not
hurt to specify it though.
If a bare filename is requested it will only be loaded if it is found within the module path as defined by the sysctl kern.module_path. To
load a module from the current directory it must be specified as a full or relative path. The kldload utility will warn if a module is
requested as a bare filename and is present in the current directory.
The following options are available:
-n Do not try to load module if already loaded.
-v Be more verbose.
-q Silence any extraneous warnings.
NOTES
The kernel security level settings may prevent a module from being loaded or unloaded by giving Operation not permitted.
FILES
/boot/kernel directory containing loadable modules. Modules must have an extension of .ko.
EXIT STATUS
The kldload utility exits 0 on success, and >0 if an error occurs.
EXAMPLES
To load by module name:
> kldload foo
To load by file name within the module path:
> kldload foo.ko
To load by relative path:
> kldload ./foo.ko
To load by full path:
> kldload /boot/kernel/foo.ko
AUTOMATICALLY LOADING MODULES
Some modules (pf, ipfw, ipf, etc.) may be automatically loaded at boot time when the corresponding rc.conf(5) statement is used. Modules may
also be auto-loaded through their addition to loader.conf(5).
SEE ALSO kldload(2), loader.conf(5), rc.conf(5), security(7), kldconfig(8), kldstat(8), kldunload(8)HISTORY
The kldload utility first appeared in FreeBSD 3.0, replacing the lkm interface.
AUTHORS
Doug Rabson <dfr@FreeBSD.org>
BSD March 18, 2012 BSD
Check Out this Related Man Page
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