container_of y las macros del kernel

El código del kernel está salpicado de macros que, si no conoces, lo vuelven ilegible. No son adorno: resuelven problemas reales de un lenguaje sin genéricos ni clases. La estrella es container_of, uno de los trucos de C más elegantes jamás escritos.

container_of: el truco maestro

Problema: tienes un puntero a un campo dentro de un struct, y quieres el puntero al struct completo. En C no hay forma directa… salvo container_of:

struct tarea {
    int id;
    struct list_head lista;    // un campo embebido
    char nombre[32];
};

// tengo un 'struct list_head *ptr' que apunta al campo .lista de una tarea.
// ¿cómo obtengo la 'struct tarea' que lo contiene?
struct tarea *t = container_of(ptr, struct tarea, lista);

Por dentro, container_of calcula el desplazamiento del campo dentro del struct (con offsetof, nivel 11 de C23) y lo resta de la dirección del campo, obteniendo la dirección del struct contenedor.

likely y unlikely

El kernel sabe qué ramas son raras (errores) y cuáles comunes, y se lo dice al compilador para que optimice la predicción de saltos:

if (unlikely(error))          // "esto casi nunca pasa"
    return -EINVAL;
if (likely(buffer_valido))    // "esto casi siempre pasa"
    procesar(buffer);

En el camino crítico (hot path) del kernel, esta pista mejora el rendimiento colocando el código común de forma que la CPU lo prediga bien. Verás unlikely en casi todas las comprobaciones de error.

El resto del arsenal

ARRAY_SIZE(arr)          // número de elementos (seguro, del kernel)
min(a, b)  max(a, b)     // con chequeo de tipos, no como las macros ingenuas
min_t(int, a, b)         // forzando un tipo
BUILD_BUG_ON(cond)       // falla la COMPILACIÓN si cond es cierta (chequeo estático)
READ_ONCE(x) / WRITE_ONCE(x)  // accesos que el compilador no puede reordenar (nivel 18)