Linus Torvalds Style Guide⁠‍⁠​‌​‌​​‌‌‍​‌​​‌​‌‌‍​​‌‌​​​‌‍​‌​​‌‌​​‍​​​​​​​‌‍‌​​‌‌​‌​‍‌​​​​​​​‍‌‌​​‌‌‌‌‍‌‌​​​‌​​‍‌‌‌‌‌‌​‌‍‌‌​‌​​​​‍​‌​‌‌‌‌‌‍​‌​​‌​‌‌‍​‌‌​‌​​‌‍‌​‌​‌‌‌​‍​​‌​‌​​​‍‌‌‌​‌​‌‌‍​‌‌‌​‌‌‌‍​‌‌​​‌​‌‍‌​‌​​‌‌‌‍​‌‌​‌‌‌‌‍​​​​‌​‌​‍​‌​‌‌‌​​⁠‍⁠

Overview

Linus Torvalds created the Linux kernel and Git, managing one of the largest collaborative software projects in history. His approach combines deep technical excellence with pragmatic decision-making and famously direct code review.

Core Philosophy

"Talk is cheap. Show me the code."

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

"Given enough eyeballs, all bugs are shallow."

Torvalds believes in practical excellence: code that works, performs well, and can be maintained by a distributed team of thousands.

Design Principles

Data Structures First: Get the data structures right; the code follows.

Performance Matters: Understand cache, branches, and memory.

Pragmatism Over Purity: Working code beats elegant theory.

Code Review Is Essential: Every patch must withstand scrutiny.

When Writing Code

Always

• Design data structures before algorithms

• Think about cache locality

• Profile before optimizing

• Write clear commit messages

• Keep patches small and focused

• Test on real hardware

Never

• Submit untested code

• Ignore performance implications

• Use abstractions that hide costs

• Write clever code that obscures intent

• Break userspace API/ABI

• Ignore reviewer feedback

Prefer

• Arrays over linked lists (cache friendly)

• Simple loops over recursion

• Inline functions over macros

• Explicit state over hidden magic

• Measured optimizations over speculative

Code Patterns

Linux Kernel Style

// kernel style: tabs, 80 columns, spaces around operators

#include <linux/kernel.h> #include <linux/slab.h>

struct device_data { struct list_head list; unsigned long flags; void __iomem *base; int irq; };

static int device_init(struct device_data *dev) { int ret;

    dev->base = ioremap(DEVICE_BASE, DEVICE_SIZE);
    if (!dev->base) {
            pr_err("Failed to map device memory\n");
            return -ENOMEM;
    }

    ret = request_irq(dev->irq, device_handler, 0, "mydev", dev);
    if (ret) {
            iounmap(dev->base);
            return ret;
    }

    return 0;

}

Data Structures Matter

// BAD: Linked list for frequently traversed data struct node { struct node *next; int value; };

// Traversal: terrible cache behavior // Each node is a cache miss

// GOOD: Array-based for cache locality struct array { int *values; size_t count; size_t capacity; };

// Traversal: sequential memory access // Prefetcher works, cache is happy

// When you need linked lists, use the kernel's #include <linux/list.h>

struct my_item { struct list_head list; // Embed the list node int data; };

struct list_head my_list; INIT_LIST_HEAD(&my_list);

// Iterate safely struct my_item *item; list_for_each_entry(item, &my_list, list) { process(item->data); }

Error Handling Patterns

// Single exit point with goto for cleanup int complex_init(struct device *dev) { int ret;

    dev->buffer = kmalloc(BUF_SIZE, GFP_KERNEL);
    if (!dev->buffer) {
            ret = -ENOMEM;
            goto err_buffer;
    }

    dev->workqueue = create_workqueue("mydev");
    if (!dev->workqueue) {
            ret = -ENOMEM;
            goto err_workqueue;
    }

    ret = register_device(dev);
    if (ret)
            goto err_register;

    return 0;

err_register: destroy_workqueue(dev->workqueue); err_workqueue: kfree(dev->buffer); err_buffer: return ret; }

// Cleanup in reverse order of initialization // One error path, easy to audit

Commit Message Excellence

subsystem: short summary (50 chars or less)

More detailed explanatory text, if necessary. Wrap it to about 72 characters. The blank line separating the summary from the body is critical.

Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how. The code shows the how.

If there are any side effects or other unintuitive consequences of this change, explain them here.

Fixes: abc123def456 ("commit that introduced bug") Reported-by: Someone <someone@example.com> Signed-off-by: Your Name <you@example.com>

Performance-Conscious Code

// Branch prediction: common case first if (likely(fast_path_condition)) { // Common case return quick_result; } // Slow path return handle_slow_case();

// Cache-friendly iteration // BAD: strided access for (int i = 0; i < rows; i++) for (int j = 0; j < cols; j++) process(matrix[j][i]); // Column-major = cache misses

// GOOD: sequential access for (int i = 0; i < rows; i++) for (int j = 0; j < cols; j++) process(matrix[i][j]); // Row-major = cache friendly

// Avoid unnecessary memory barriers // Use READ_ONCE/WRITE_ONCE for shared data int value = READ_ONCE(shared_variable); WRITE_ONCE(shared_variable, new_value);

Git Usage

Torvalds Git workflow

Commit often, commit small

git add -p # Stage hunks, not files git commit -m "subsystem: specific change"

Rebase for clean history (before sharing)

git rebase -i HEAD~5 # Clean up local commits

Never rebase published history

History is sacred once pushed

Bisect to find bugs

git bisect start git bisect bad HEAD git bisect good v5.10

Git finds the breaking commit

Blame to understand code

git blame -w -C -C file.c # Ignore whitespace, track moves

Subsystem Design

// Define clear boundaries between subsystems // Each subsystem has: // 1. Public API (exported symbols) // 2. Internal implementation // 3. Data structures

// Public API int subsystem_init(void); void subsystem_cleanup(void); int subsystem_do_thing(struct thing *t);

// Internal - not exported static int internal_helper(void); static struct cache internal_cache;

// Use proper namespacing // subsystem_verb_noun()

int netdev_register_device(struct net_device *dev); int netdev_unregister_device(struct net_device *dev); int blkdev_read_sector(struct block_device *bdev, sector_t sector);

Reference Counting

#include <linux/kref.h>

struct my_object { struct kref refcount; // ... other fields };

static void my_object_release(struct kref *kref) { struct my_object *obj = container_of(kref, struct my_object, refcount); kfree(obj); }

// Get reference struct my_object *my_object_get(struct my_object *obj) { if (obj) kref_get(&obj->refcount); return obj; }

// Release reference void my_object_put(struct my_object *obj) { if (obj) kref_put(&obj->refcount, my_object_release); }

Mental Model

Torvalds approaches systems code by asking:

• What are the data structures? Design these first

• What's the cache behavior? Memory access patterns matter

• What's the common case? Optimize for it

• Can I review this easily? Clear code, small patches

• What breaks if this is wrong? Systems code must be reliable

Signature Torvalds Moves

• Data structures before algorithms

• goto for cleanup (in kernel code)

• likely/unlikely for branch hints

• Cache-conscious data layout

• Small, focused commits

• Direct, honest code review