Difference between revisions of "Kernel Competence"

From GhostBSD Wiki
Jump to: navigation, search
(Modules)
 
(25 intermediate revisions by the same user not shown)
Line 3: Line 3:
  
 
==Introduction==
 
==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.
+
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.<br/>
 +
[https://github.com/freebsd/freebsd/blob/master/sys/conf/NOTES '''NOTES''']: Lines that can be cut/pasted into kernel and hints configs.<br/>
 +
* Lines that begin with ''device'', ''options'', ''machine'', ''ident'', ''maxusers'', ''makeoptions'', ''hints'', etc. go into the kernel configuration that you run [https://www.freebsd.org/cgi/man.cgi?query=config&apropos=0&sektion=8&manpath=FreeBSD+5.0-RELEASE&arch=default&format=html 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==
 
==Kernel==
Line 10: Line 13:
  
 
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.
 
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 [https://www.freebsd.org/cgi/man.cgi?query=kenv&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html 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==
 
==Modules==
  
The kernel and any modules included with GhostBSD are files in the directory ''/boot/kernel''.
+
The kernel and any modules included with GhostBSD are files in the directory '''/boot/[[Kernel|kernel]]'''.
Third-party modules are located in ''/boot/modules''. Not all modules are loaded by default. If needed, one can load them later.<br/>
+
Third-party modules are located in '''/boot/[[Modules|modules]]'''. Not all modules are loaded by default. If needed, one can load them later.<br/>
 +
All files elsewhere on the system or in the [https://www.freebsd.org/ports/kld.html 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 [https://www.freebsd.org/cgi/man.cgi?query=kldload&apropos=0&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html kldload(8)] and [https://www.freebsd.org/cgi/man.cgi?query=kldunload&apropos=0&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html kldunload(8)].
 +
 
 +
'''Example:''' You want to load ''vboxdrv.ko,'' listed in '''/boot/[[Modules|modules]]/vboxdrv.ko''' as a third-party kernel module. You simply chop of ''/boot/modules/''  and the ''.ko'' extention and write in a terminal:<br/>
 +
<code><nowiki>#</nowiki> kldload vboxdrv</code><br/>
 +
 
 +
The following options are available:<br/>
 +
{|
 +
|<nowiki>-n</nowiki> 
 +
|Do not try to load module if already loaded.
 +
|-
 +
|<nowiki>-v</nowiki> 
 +
|Be more verbose.
 +
|-
 +
|<nowiki>-q </nowiki>
 +
|Silence any extraneous warnings.
 +
|}
 +
 
 +
To unload this module you write:<br/>
 +
<code><nowiki>#</nowiki> kldunload vboxdrv</code><br/>
 +
 
 +
The following options are available:<br/>
 +
{|
 +
|style="vertical-align:top|<nowiki>-f</nowiki>
 +
|
 +
|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.
 +
|-
 +
|<nowiki>-v</nowiki>
 +
|
 +
|Be more verbose.
 +
|-
 +
|<nowiki>-i</nowiki>
 +
|''id''
 +
|Unload the file with this ID.
 +
|-
 +
|<nowiki> -n</nowiki>
 +
|''name''
 +
|Unload the file with this name.
 +
|}
 +
 
 +
'''NOTES'''<br/>
 +
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.<br/>
 +
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: <code>_load="YES"</code>
 +
 
 +
For example:<br/>
 +
 
 +
<code>vboxdrv_load="YES"</code>
  
There are also loadable modules located in the repositories or ports: [https://www.freebsd.org/ports/kld.html].
+
==[[Sysctl]]==   
  
==Kernel Tools==  
+
With [[Sysctl] you will get information obout your kernel version and much more.<br/>
 +
The simplest and best supported way to alter a kernel is to use the '''[[sysctl]]''' interface. The [https://www.freebsd.org/cgi/man.cgi?query=sysctl&apropos=0&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html 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.
  
  

Latest revision as of 04:45, 27 March 2020

Welcome to Icon Disti GhostBSD.png Kernel Competence.
Kernel Competence
Sysctl Kldstat Third-party Kernel Modules
Kernel Modules FreeBSD Ports: Kld Kenv
Compiling a new GhostBSD kernel
Back to the Icon Disti GhostBSD.pngSystem

Introduction[edit]

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[edit]

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[edit]

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[edit]

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

Modules[edit]

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[edit]

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[edit]

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[edit]

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.