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

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.

kldstat

The kldstat utility displays the status of any files dynamically linked into the kernel.

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

With [[Sysctl] you will get information obout your kernel version and much more.
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.