<P> A downloadable kernel module (DKM) type project can be created to generate a ". out" file which can then be loaded to kernel space using "ld" command . This downloadable kernel module can be unloaded using "unld" command . </P> <P> Solaris has a configurable kernel module load path, it defaults to / platform / platform - name / kernel / kernel / usr / kernel . Most kernel modules live in subdirectories under / kernel; those not considered necessary to boot the system to the point that init can start are often (but not always) found in / usr / kernel . When running a DEBUG kernel build the system actively attempts to unload modules . </P> <P> Linux does not provide a stable API or ABI for kernel modules . This means that there are differences in internal structure and function between different kernel versions, which can cause compatibility problems . In an attempt to combat those problems, symbol versioning data is placed within the . modinfo section of loadable ELF modules . This versioning information can be compared with that of the running kernel before loading a module; if the versions are incompatible, the module will not be loaded . </P> <P> Other operating systems, such as Solaris, FreeBSD, macOS, and Windows keep the kernel API and ABI relatively stable, thus avoiding this problem . For example, FreeBSD kernel modules compiled against kernel version 6.0 will work without recompilation on any other FreeBSD 6. x version, e.g. 6.4 . However, they are not compatible with other major versions and must be recompiled for use with FreeBSD 7. x, as API and ABI compatibility is maintained only within a branch . </P>

Windows systems also provide support for dynamically loadable kernel modules