Getting started with kernel projects

First, don't be afraid of the kernel. In the kernel, you have to live with some constraints and debugging is more challenging, but it's not an order of magnitude harder than userland. Moreover, we are porting existing working code.


Source code locations

In Linux, DRM is located in three places:

In FreeBSD, DRM is in two places:


The workflow and target were discussed in the thread below:

The conclusion is in a separate thread:

During the discussion, some wanted to work on Linux 3.9, some on Linux 4.3/4.4.

That said, I believe we should start by moving to linuxkpi before anything. It would consist of modifying DRM to use sys/compat/linuxkpi instead of its own drm_os_freebsd.[ch] files. This would help a lot during the next updates.


The file-by-file workflow was more popular in the discussion, and is explained in the second link above.

As for the branches, we are going to use drm-next-$target (eg. drm-next-3.9). Please send pull requests to these branches. At least in freebsd-base-graphics, master will remain the same code as Subversion's HEAD so we have a point of comparison.

Let's take drm-next-3.9 as an example. We want to update the entire DRM to Linux 3.9: DRM core (the device-independent code), the i915 driver and the Radeon driver.

As we are testing the file-by-file approach, we need to coordinate who does what. And before the task is finished, the kernel won't compile. That is the risk with the file-by-file approach.

I would like to record all the contributors on the wiki or on GitHub, I'm not sure yet. Maybe it should take the form of issues on GitHub (that is, one issue per file to update and an assignee). The issue even lets us discuss specific details about the file.

DRM core should be updated first, then the drivers.

How to build

I usually build a full kernel:

make buildkernel

Then, after some work, I can rebuild the DRM part:

make buildkernel -DKERNFAST DEBUG_FLAGS="-g -O0"

Add -j$N to accelerate the build.

You can't use -O0 for the entire kernel, it will cause stack overflows. However, use it for subsequent rebuilds (that is, when using -DKERNFAST). Otherwise, you'll get a lot of "<optimized out>" variables in gdb.

When working on the update of a single file, you move that file to the top of $(SRCS) in the Makefile (for example, sys/modules/drm2/drm2/Makefile) so other files don't prevent build-testing your work.

I (re)install the new kernel in /tmp, because I use tmpfs there (I don't care about the installed kernel on my working computer):

make installkernel DESTDIR=/tmp
# or, after a first install
make reinstallkernel DESTDIR=/tmp

From the test computer, I rsync the new kernel.

How to Test

Do not load the driver from /boot/loader.conf or /etc/rc.conf. Load it manually after boot.

You can set drm.debug=7 in /boot/loader.conf to have more debug information during kldload. If the log level is too verbose, it can be lowered later with the hw.dri.debug sysctl.

Play with several applications and use cases. I use:

If you find a problem, try to reduce it to the minimum, then:

  1. From a remote computer, use tmux or screen for your session (not mandatory, but quite handy)
  2. From one tab, start a plain X server:

  3. From another tab, start the bad, bad program:

    DISPLAY=:0 bad_application
  4. Use other tabs to look at log files, run dtrace scripts, and so on.

By doing so, you limit the number of calls to the video drivers to the minimum. Running a full desktop environment will spam a lot of unrelated messages.

If the computer doesn't crash and you want to load a newer driver:

  1. Close all applications and the X server
  2. kldunload the driver (note that it doesn't work for i915kms in HEAD, the update will fix that)

  3. kldload the new one.

It saves you a reboot. Again, do this from a remote computer because after kldunloading, you may not get a console back. It works with the Radeon driver, but so far, not with the updated i915 driver.

If you get a core dump, it will be available in /var/crash after the reboot. Usually, core.txt.$N has enough information. If not, you can start gdb (either the one in base or the one from Ports):

# Change "/boot/kernel/kernel" to match the kernel you used
kgdb /boot/kernel/kernel /var/crash/vmcore.last

Books and documentation

I recommend the following two books:

Additionally, Daniel Vetter from Intel wrote a series of nice articles about the i915 driver.


GraphicsOld/Getting started with kernel projects (last edited 2021-03-28T08:34:10+0000 by KubilayKocak)