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-defined coding style described in Documentation/process/coding-style.rst. Reviewers routinely reject patches that do not follow it, and many will not even read the code until the style is corrected. The rules below come directly from the kernel’s own documentation.

​
Indentation

Tabs are 8 characters wide. Indentation uses tabs, not spaces. 
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;
}
The switch and its case labels align at the same column. Never double-indent case labels.
8-character indentation is intentional. If your code reaches more than three levels of nesting, that is a signal to refactor — not a reason to switch to 4-space indents.
Lines should be kept to 80 columns where possible. The current checkpatch limit is 100 columns, but staying within 80 is preferred. Never break user-visible strings (such as printk messages) across lines, because that prevents grepping for them.

​
Placing braces

The kernel follows K&R style. For all non-function statement blocks (if, switch, for, while, do), the opening brace goes at the end of the line: 
if (x == y) {
	we do y
}
Functions are the exception — their opening brace goes on its own line: 
int function(int x)
{
	body of function
}
The closing brace stands alone on its line, except when followed by a continuation (else, while in a do-while): 
if (x == y) {
	..
} else if (x > y) {
	...
} else {
	....
}
Do not add braces around a single-statement body unless the other branch of the same conditional has multiple statements: 
if (condition)
	action();

​
Spaces

Use a space after 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: 
/* bad */
s = sizeof( struct file );

/* good */
s = sizeof(struct file);
Place * adjacent to the variable or function name, not the type: 
char *linux_banner;
unsigned long long memparse(char *ptr, char **retptr);

​
Naming

Global functions and variables need descriptive names. A function that counts active users should be named count_active_users(), not cntusr(). Local variables can be short — a loop counter is i, a temporary value is tmp. CamelCase is not used. Use lowercase_with_underscores for all identifiers. Hungarian notation (encoding types into names) is explicitly discouraged — the compiler already knows the types. For new symbol names, avoid the terms master/slave and blacklist/whitelist. Preferred replacements include:
  • primary / secondary or initiator / target instead of master / slave
  • allowlist / denylist instead of whitelist / blacklist

​
Typedefs

Avoid typedef for structures and pointers. When code says vps_t a;, you cannot tell what a is. When it says struct virtual_container *a;, you can. Typedefs are acceptable only for:
  • Truly opaque objects (accessed only through accessor functions)
  • Fixed-width integer types where the abstraction is meaningful (u8, u16, u32, u64)
  • Types created specifically for sparse type-checking

​
Functions

Functions should be short and do one thing. The guideline is one or two screenfuls of text at 80×24. If a function needs more than 5–10 local variables, it is too complex and should be split. 
int system_is_up(void)
{
	return system_state == SYSTEM_RUNNING;
}
EXPORT_SYMBOL(system_is_up);
EXPORT_SYMBOL immediately follows the closing brace of an exported function. For centralized cleanup, goto is idiomatic in kernel code: 
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: is good, err1: is not.

​
Comments

Comments should say what the code does and why, not how. Never use comments to explain badly-written code — fix the code instead. The preferred multi-line comment style 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.
 */
Single-line C99 comments (//) are not used. Use the block comment style consistently. For API documentation, use the kernel-doc format (see Documentation/doc-guide/). Do not add boilerplate kernel-doc that simply restates what the function signature already says.

​
Macros

Macro names that define constants and enum labels are capitalized: #define CONSTANT 0x12345. Function-like macros may use lowercase. Prefer static inline functions over function-like macros. Inline functions are type-safe, do not evaluate arguments multiple times, and are easier to debug. Multi-statement macros must be enclosed in do { } while (0): 
#define macrofun(a, b, c)			\
	do {					\
		if (a == 5)			\
			do_this(b, c);		\
	} while (0)
Things to avoid in macros:
  • Macros that affect control flow (hidden return statements)
  • Macros that depend on a local variable with a magic name
  • Macros with arguments used as l-values

​
Error handling

Functions that are commands (imperative names like add_work) return 0 on success and a negative errno value on failure. Functions that are predicates (like pci_dev_present) return a boolean where non-zero means success. 
/* command: returns error code */
int add_work(struct workqueue_struct *wq, struct work_struct *work);

/* predicate: returns bool */
int pci_dev_present(const struct pci_device_id *ids);
Do not add new BUG() or BUG_ON() calls. Use WARN_ON_ONCE() instead, and include recovery code where possible.

​
Validating style with checkpatch.pl

Before submitting any patch, run it through scripts/checkpatch.pl: 
./scripts/checkpatch.pl mypatch.patch
Checkpatch reports three levels of messages:
LevelMeaning
ERRORVery likely wrong; must be addressed
WARNINGRequires careful review
CHECKRequires thought; enabled with --strict
Checkpatch is a guide, not a law. If fixing a complaint would make the code less readable, leave it and be prepared to explain why in your cover letter or commit message.
You can also use clang-format with the kernel’s .clang-format file for automatic reformatting, and editors that support EditorConfig will pick up the kernel’s indentation settings automatically from the .editorconfig file in the tree root.

Build docs developers (and LLMs) love

Get started for freeTalk to us