1. What Is printk() and Why Does It Exist?

In user-space C programs you call printf() to write text to a terminal. The kernel runs long before any terminal exists, so it has its own equivalent: printk(). The name is short for print kernel.

Every kernel subsystem, every driver, and every loadable module uses printk() to write diagnostic and status messages. Those messages go into a ring buffer inside the kernel called the kernel log buffer. You can read it at any time with the dmesg command.

In Linux 6.x the log-level macros available to you are:

/* Log level constants defined in <linux/kern_levels.h> */
KERN_EMERG    /* system is unusable                         */
KERN_ALERT    /* action must be taken immediately           */
KERN_CRIT     /* critical conditions                        */
KERN_ERR      /* error conditions                           */
KERN_WARNING  /* warning conditions                        */
KERN_NOTICE   /* normal but significant condition           */
KERN_INFO     /* informational                              */
KERN_DEBUG    /* debug-level messages                       */

Instead of embedding these raw strings into every printk() call, the kernel provides convenience wrappers like pr_info(), pr_err(), pr_warn(), and pr_debug(). These automatically attach the right log-level prefix for you.

2. The Problem With Raw printk() Calls

Imagine you are debugging a kernel module called mydriver and it loads fine but something goes wrong after a few seconds. You run dmesg and see hundreds of log lines from multiple subsystems. How do you quickly find which lines came from your module?

If you wrote bare pr_info("init done\n") calls, the kernel log only shows the log-level and timestamp. Nothing identifies your module or the specific function that printed the message. Finding the relevant lines becomes a slow, manual process.

The Linux kernel community solved this long ago with a simple macro you define once at the top of each source file.

3. Introducing pr_fmt() — Your Automatic Log Prefix

The pr_fmt() macro acts as a format string preprocessor. Every time a pr_*() convenience function (like pr_info() or pr_err()) is called, it first passes the format string through pr_fmt(). Whatever pr_fmt() returns becomes the actual format string used in the log entry.

By defining pr_fmt() at the top of your source file, before any includes, you inject a consistent prefix into every single log message your file emits — with zero repetition in individual pr_info() calls.

/* Define pr_fmt() at the very top of your .c file,
   BEFORE any #include statements */

#define pr_fmt(fmt)  KBUILD_MODNAME ": " __func__ ": " fmt

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");

static int __init my_driver_init(void)
{
    pr_info("driver inserted\n");
    /* The kernel log will show:
       [  123.456789] mydriver: my_driver_init: driver inserted */
    return 0;
}

static void __exit my_driver_exit(void)
{
    pr_info("driver removed\n");
    /* The kernel log will show:
       [  456.789012] mydriver: my_driver_exit: driver removed */
}

module_init(my_driver_init);
module_exit(my_driver_exit);

4. KBUILD_MODNAME and __func__ — The Two Pillars

KBUILD_MODNAME

This is a string constant the Kbuild build system automatically defines for you during compilation. Its value is the name of the kernel module being built — exactly the name of your .ko file without the extension. You never have to hard-code your module name in a string; the build system does it for you.

If your module file is serial_gpio_driver.c and the Makefile builds it as serial_gpio_driver.ko, then KBUILD_MODNAME expands to the string "serial_gpio_driver" at compile time.

__func__

This is a standard C99 predefined identifier. The compiler replaces it with a string literal containing the name of the current function. It is not a macro — it is a language feature, so it correctly resolves to the right function name even when the same header is included from many places.

5. Including Line Numbers in Log Output

Sometimes a function is long and you want to know not just which function printed a message, but at which exact line inside that function. The C preprocessor provides the __LINE__ macro for this. You can include it inline in your format string using a %d specifier.

/* Logging the line number alongside the message */
pr_info("checkpoint reached at line %d\n", __LINE__);

This produces output like:

[  789.012345] mydriver: my_driver_init: checkpoint reached at line 42

6. pr_fmt() and dev_<foo>() — Device Driver Logging

For platform and character device drivers, the kernel provides a separate family of logging functions: dev_info(), dev_err(), dev_warn(), and others. These take a pointer to a struct device as their first argument and automatically prepend the device name to the log message.

The pr_fmt() macro also feeds into these functions under the hood. This means your module-level prefix and the device name both appear in the log line, giving you two levels of context at once.

/* Inside a probe function for a platform driver */
static int my_device_probe(struct platform_device *pdev)
{
    dev_info(&pdev->dev, "device probed successfully\n");
    /* Output in kernel log:
       [  100.000001] mydriver mydevice0: device probed successfully */
    return 0;
}

7. Reading Kernel Log Messages in Linux 6.x

Linux 6.x changed how /dev/kmsg works compared to older kernels. The structured log format now carries additional metadata fields. Here are the main ways to read kernel log output:

8. pr_debug() — Conditional Debug Logging

The pr_debug() function is special. By default, when you call it, it compiles down to a no-op — the message is completely removed from the binary and has zero runtime cost. This means you can leave debug statements in your production code without any performance penalty.

To activate pr_debug() output for a specific module, you enable the DEBUG preprocessor flag when compiling that module. There are two ways to do this:

# Method 1: Add to EXTRA_CFLAGS in your module's Makefile
EXTRA_CFLAGS += -DDEBUG

# Method 2: Define it at the top of the specific .c file
#define DEBUG
#define pr_fmt(fmt) KBUILD_MODNAME ": " __func__ ": " fmt
#include <linux/kernel.h>