The snippets, ordered obscure → unmistakable

  1. Snippet 1(min/max macros (everywhere in the tree))
  2. Snippet 2(lib/list.h-style idiom)
  3. Snippet 3(container_of macro family)
  4. Snippet 4(task_struct fragment)
  5. Snippet 5(init/main.c bootstrap)
  6. Snippet 6(drivers/* MODULE_LICENSE pattern)

Why this project gives itself away

The give-away. Snippet 1's GCC statement-expression ({ ... }) plus typeof() macros is a classic kernel idiom (and a familiar trap — userspace MIN macros double-evaluate). Snippet 2 reveals the intrusive linked list — struct list_head embedded in every container is kernel folklore. Snippet 3's container_of macro is the canonical Linux pointer-arithmetic trick. Snippet 4 names task_struct and sched_class, which are unmistakable. Snippet 5's __init, pr_notice, linux_banner, start_kernel close it. Snippet 6 finally credits Linus and MODULE_LICENSE("GPL v2").

Why this style. The kernel deliberately avoids the C standard library and rolls its own primitives (lists, hash tables, refcounts) on top of GCC extensions. The result is a recognisable house style you can spot from a single macro.

How a Framed puzzle is built

Every Framed project ships exactly six snippets, hand-ordered from deeply obscure to unmistakable. The first snippet must be plausible for a dozen codebases — a generic loop, a small utility, a comment that could appear anywhere. The last snippet carries a project-specific tell: a function name, a code-comment idiom, a file header, a build invocation. Between them sit four snippets that gradually narrow the field. Reading them in order is half the puzzle: a returning Framed player learns to triangulate on indentation conventions, comment voice, naming, and the small-but-distinctive choices that betray a project's era and community.

↳ Public include/linux/list.h and init/main.c structure.