Kernel Competence
Welcome to Kernel Competence. |
Kernel Competence | ||
---|---|---|
Sysctl | Kldstat | Third-party Kernel Modules |
Kernel Modules | FreeBSD Ports: Kld | Kenv |
Compiling a new GhostBSD kernel | ||
Back to the System |
Contents
Introduction
On this page and its sub-pages we will collect all information connect to the kernel, like managing kernel modules, retrieve information from the kernel and use special commands.
NOTES: Lines that can be cut/pasted into kernel and hints configs.
- Lines that begin with device, options, machine, ident, maxusers, makeoptions, hints, etc. go into the kernel configuration that you run config(8) with.
- Lines that begin with 'hint.' are NOT for config(8), they go into your hints file. See /boot/device.hints and/or the 'hints' config(8) directive.
Kernel
The kernel is the interface between the hardware and the software. The kernel lets the software write data to disk drives and to network. When a program needs memory, the kernel handles the access to the physical memory chip. When a program requests CPU time, the kernel organizes it. The kernel provides all the software interfaces that a program needs, in order to access hardware resources.
To follow the UNIX philosophy: to minimalist, modular software development the Ghost/FreeBSD kernel is set together out of modules. If a hardware requires a special piece of software, a appropriate module has to be loaded in to the working memory. Not needed modules stay on the hard disc or the software repositories.
Kenv
The kernel is started by the boot loader. The boot loader delivers environment variables to the kernel. Together they form the kernel environment. The kernel and its environment form also a MIB tree, like the sysctl tree. With the kenv(8) utility you can view the kernel environment.
Modules
The kernel and any modules included with GhostBSD are files in the directory /boot/kernel.
Third-party modules are located in /boot/modules. Not all modules are loaded by default. If needed, one can load them later.
All files elsewhere on the system or in the ports called the userland, meaning they are intended for users even if they use kernel facilities.
Loading and Unloading Modules on a running System
Loading and unloading kernel modules is done with kldload(8) and kldunload(8).
Example: You want to load vboxdrv.ko, listed in /boot/modules/vboxdrv.ko as a third-party kernel module. You simply chop of /boot/modules/ and the .ko extention and write in a terminal:
# kldload vboxdrv
The following options are available:
-n | Do not try to load module if already loaded. |
-v | Be more verbose. |
-q | Silence any extraneous warnings. |
To unload this module you write:
# kldunload vboxdrv
The following options are available:
-f | Force the unload. This ignores error returns to MOD_QUIESCE from the module and implies that the module should be unloaded even if it is currently in use. The users are left to cope as best they can. | |
-v | Be more verbose. | |
-i | id | Unload the file with this ID. |
-n | name | Unload the file with this name. |
NOTES
The kernel security level settings may prevent a module from being loaded or unloaded by giving Operation not permitted.
Loading Modules at Boot
Normally you want to load a kernel module automatically at boot.
You have to make an entry in the /boot/loader.conf file.
The procedure is always the same: Take the name of the kernel module and add: _load="YES"
For example:
vboxdrv_load="YES"
sysctl
The simplest and best supported way to alter a kernel is to use the sysctl interface. The sysctl(8) allows you to retrieve the values used by the kernel and in some cases to set them.
sysctl is a very powerful program. You can solve performance issues but also crash your system.