Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/deelerdev/linux/llms.txt

Use this file to discover all available pages before exploring further.

The Linux kernel has a well-established coding style that has evolved over decades. Consistency across several million lines of C code makes the codebase readable to a large number of contributors who did not write any given piece of code. Style violations slow down review — a patch that ignores these conventions is likely to be returned for cleanup before it is even read for correctness. The following sections cover the most important rules, with code examples drawn directly from the kernel style guide.

​
Indentation

Indentation uses tabs, and each tab is 8 characters wide. There are no exceptions for C source files outside of comments and Kconfig. 
switch (suffix) {
case 'G':
case 'g':
	mem <<= 30;
	break;
case 'M':
case 'm':
	mem <<= 20;
	break;
case 'K':
case 'k':
	mem <<= 10;
	fallthrough;
default:
	break;
}
Note how switch and its case labels are aligned in the same column rather than double-indenting the cases. If your code needs more than three levels of indentation you should probably restructure it — deep nesting is a sign the function is doing too much.
Spaces are never used for indentation in C source files. Using 4-space or 2-space indents is not acceptable in kernel code, regardless of what your editor defaults to.

​
Line length

The preferred limit on a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks. Descendants of a broken line are placed substantially to the right of the parent, often aligned to the opening parenthesis of a function call. Do not break user-visible strings such as printk messages, because that breaks the ability to grep for them.

​
Placing braces

The kernel follows the Kernighan and Ritchie (K&R) brace style: the opening brace goes at the end of the line that opens the block, and the closing brace goes on a line of its own. 
if (x == y) {
	..
} else if (x > y) {
	...
} else {
	....
}
Functions are the one exception: their opening brace appears on the next line. 
int function(int x)
{
	body of function
}
Omit braces when a single statement fills the entire branch: 
if (condition)
	action();
But when one branch of a conditional is multi-statement, use braces in both branches: 
if (condition) {
	do_this();
	do_that();
} else {
	otherwise();
}

​
Spaces

Use a space after these keywords: if, switch, case, for, do, while. Do not add a space after sizeof, typeof, alignof, or __attribute__. 
s = sizeof(struct file);
Do not add spaces inside parenthesized expressions: 
/* Wrong */
s = sizeof( struct file );
Place the * adjacent to the variable name, not the type name, when declaring pointer types: 
char *linux_banner;
unsigned long long memparse(char *ptr, char **retptr);
char *match_strdup(substring_t *s);
Use one space on each side of binary and ternary operators (=, +, -, <, >, *, /, %, |, &, ^, <=, >=, ==, !=, ?, :). Use no space after unary operators (&, *, +, -, ~, !).

​
Naming

Local variable names should be short and to the point. A simple loop counter should be called i, not loop_counter. A temporary value should be tmp. Hungarian notation (encoding the type into the name) is not used.
Avoid introducing new usage of master/slave or blacklist/whitelist in symbol names or documentation. Preferred replacements include primary/secondary, initiator/target, controller/device, leader/follower, denylist/allowlist, and blocklist/passlist.

​
Functions

Functions should do one thing and do it well. The practical guideline is that a function should fit on one or two screenfuls (80×24 characters). The maximum length is inversely proportional to the function’s complexity and indentation depth. If a function is exported, the EXPORT_SYMBOL macro follows immediately after the closing brace: 
int system_is_up(void)
{
	return system_state == SYSTEM_RUNNING;
}
EXPORT_SYMBOL(system_is_up);
Functions that have multiple exit points should use a single cleanup label at the bottom rather than duplicating cleanup code at each exit: 
int fun(int a)
{
	int result = 0;
	char *buffer;

	buffer = kmalloc(SIZE, GFP_KERNEL);
	if (!buffer)
		return -ENOMEM;

	if (condition1) {
		while (loop1) {
			...
		}
		result = 1;
		goto out_free_buffer;
	}
	...
out_free_buffer:
	kfree(buffer);
	return result;
}
Choose label names that describe what the goto does — out_free_buffer rather than err1.

​
Typedefs

The kernel style guide is explicit: do not use typedefs for structures and pointers. When you see vps_t a; you cannot tell what it is. When you see struct virtual_container *a; you can. Typedefs are acceptable only in a small set of situations:
  • Opaque objects that can only be accessed through accessor functions (e.g. pte_t).
  • Clear integer types where the abstraction avoids confusion between int and long (e.g. u8, u16, u32, u64).
  • New types for sparse type-checking.
  • Standard C99 equivalents — the kernel’s u8/u16/u32/u64 types are permitted though not mandatory in new code.
  • Types safe for use in userspace — use __u32 and similar in structures shared with userspace.

​
Comments

Comments should tell you what code does, not how it does it. Never use a comment to explain poorly written code — rewrite the code instead. The preferred style for multi-line comments is: 
/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */
API documentation uses the kernel-doc format. See Documentation/doc-guide/ and tools/docs/kernel-doc for the format specification. Avoid over-commenting: if a function requires extensive inline comments to explain its logic, it is probably too complex and should be broken up.

​
Macros

Macros with multiple statements must be enclosed in a do ... while (0) block:
#define macrofun(a, b, c)			\
	do {					\
		if (a == 5)			\
			do_this(b, c);		\
	} while (0)
  • Macros that affect control flow (e.g. return inside a macro): they look like function calls but exit the calling function.
  • Macros that depend on a local variable with a magic name.
  • Macros with arguments that are used as l-values.
  • Constants defined without parentheses around the expression — always write #define CONSTEXP (CONSTANT | 3).
Function-like macros with unused parameters should be replaced by static inline functions. Inline functions avoid the “expression evaluated more than once” problem and are better documented by tools.
static inline void fun(struct foo *foo)
{
}

​
Memory allocation

The preferred form for allocating a struct uses sizeof(*p) rather than spelling out the type name: 
p = kmalloc(sizeof(*p), ...);
For arrays, use kmalloc_array or kcalloc, which check for multiplication overflow: 
p = kmalloc_array(n, sizeof(...), ...);
p = kcalloc(n, sizeof(...), ...);

​
Editor configuration

Configure your editor to use real tabs of 8 characters and to show or strip trailing whitespace. Git will warn you if your patches introduce trailing whitespace. For Emacs, place the configuration from the style guide into your .emacs and point it at your kernel source tree. For other editors, the kernel ships an .editorconfig file at the tree root that sets the basic indentation and line-ending rules automatically for EditorConfig-compatible editors. You can also use clang-format with the kernel’s .clang-format configuration to auto-reformat code and spot style mistakes: 
clang-format -i path/to/file.c
See Documentation/dev-tools/clang-format.rst for full details.

Build docs developers (and LLMs) love

Get started for freeTalk to us