Source string Read only

(itstool) path: sect1/para
Context English State
Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol.
$FreeBSD: head/en_US.ISO8859-1/articles/geom-class/article.xml 54291 2020-06-23 13:48:26Z emaste $
This text documents some starting points in developing GEOM classes, and kernel modules in general. It is assumed that the reader is familiar with C userland programming.
Documentation on kernel programming is scarce — it is one of few areas where there is nearly nothing in the way of friendly tutorials, and the phrase <quote>use the source!</quote> really holds true. However, there are some bits and pieces (some of them seriously outdated) floating around that should be studied before beginning to code:
The <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/developers-handbook/index.html">FreeBSD Developer's Handbook</link> — part of the documentation project, it does not contain anything specific to kernel programming, but rather some general useful information.
The <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/arch-handbook/index.html">FreeBSD Architecture Handbook</link> — also from the documentation project, contains descriptions of several low-level facilities and procedures. The most important chapter is 13, <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics.html">Writing FreeBSD device drivers</link>.
The Blueprints section of <link xlink:href="">FreeBSD Diary</link> web site — contains several interesting articles on kernel facilities.
The man pages in section 9 — for important documentation on kernel functions.
The <citerefentry><refentrytitle>geom</refentrytitle><manvolnum>4</manvolnum></citerefentry> man page and <link xlink:href="">PHK's GEOM slides</link> — for general introduction of the GEOM subsystem.
Man pages <citerefentry><refentrytitle>g_bio</refentrytitle><manvolnum>9</manvolnum></citerefentry>, <citerefentry><refentrytitle>g_event</refentrytitle><manvolnum>9</manvolnum></citerefentry>, <citerefentry><refentrytitle>g_data</refentrytitle><manvolnum>9</manvolnum></citerefentry>, <citerefentry><refentrytitle>g_geom</refentrytitle><manvolnum>9</manvolnum></citerefentry>, <citerefentry><refentrytitle>g_provider</refentrytitle><manvolnum>9</manvolnum></citerefentry> <citerefentry><refentrytitle>g_consumer</refentrytitle><manvolnum>9</manvolnum></citerefentry>, <citerefentry><refentrytitle>g_access</refentrytitle><manvolnum>9</manvolnum></citerefentry> &amp; others linked from those, for documentation on specific functionalities.
The <citerefentry><refentrytitle>style</refentrytitle><manvolnum>9</manvolnum></citerefentry> man page — for documentation on the coding-style conventions which must be followed for any code which is to be committed to the FreeBSD tree.
The best way to do kernel development is to have (at least) two separate computers. One of these would contain the development environment and sources, and the other would be used to test the newly written code by network-booting and network-mounting filesystems from the first one. This way if the new code contains bugs and crashes the machine, it will not mess up the sources (and other <quote>live</quote> data). The second system does not even require a proper display. Instead, it could be connected with a serial cable or KVM to the first one.
But, since not everybody has two or more computers handy, there are a few things that can be done to prepare an otherwise <quote>live</quote> system for developing kernel code. This setup is also applicable for developing in a <link xlink:href="">VMWare</link> or <link xlink:href="">QEmu</link> virtual machine (the next best thing after a dedicated development machine).
Modifying a System for Development
For any kernel programming a kernel with <option>INVARIANTS</option> enabled is a must-have. So enter these in your kernel configuration file:
For more debugging you should also include WITNESS support, which will alert you of mistakes in locking:
options WITNESS
For debugging crash dumps, a kernel with debug symbols is needed:
makeoptions DEBUG=-g
With the usual way of installing the kernel (<command>make installkernel</command>) the debug kernel will not be automatically installed. It is called <filename>kernel.debug</filename> and located in <filename>/usr/obj/usr/src/sys/KERNELNAME/</filename>. For convenience it should be copied to <filename>/boot/kernel/</filename>.
Another convenience is enabling the kernel debugger so you can examine a kernel panic when it happens. For this, enter the following lines in your kernel configuration file:
options KDB
options DDB
options KDB_TRACE
For this to work you might need to set a sysctl (if it is not on by default):
Kernel panics will happen, so care should be taken with the filesystem cache. In particular, having softupdates might mean the latest file version could be lost if a panic occurs before it is committed to storage. Disabling softupdates yields a great performance hit, and still does not guarantee data consistency. Mounting filesystem with the <quote>sync</quote> option is needed for that. For a compromise, the softupdates cache delays can be shortened. There are three sysctl's that are useful for this (best to be set in <filename>/etc/sysctl.conf</filename>):


No matching activity found.

Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/geom-class.pot, string 21