Quotes of the week

Linus made an interesting observation: he enjoys doing merges in C and has become exceptionally good at it through decades of experience - he can "do them in his sleep". But he also observed that merges in Rust are more difficult as he's not familiar enough with the language. He tries to resolve them himself, then refers back to linux-next's resolution. When his resolution doesn't match, he uses it as a teaching moment.

This observation points to something fundamental about merge conflict resolution: it is the epitome of understanding code. To resolve a conflict, one must understand why the divergence occurred, what the developers on each side were trying to accomplish, and then unify the divergence in a way that makes the final code equal to or better than the sum of both parts.

LLMinus is a tool designed to support a maintainer's decision making around merge conflict resolution by learning from past merges as well as investigating into the different branches, trying to understand the underlying reason behind a conflict.

The Linux kernel's mm system weighs in at about 200KLoC, and Lorenzo [Stoakes] wrote a book on its design that weighs in at about 1300 pages, or about 150 LoC/page. This suggests that the Linux-kernel scheduler, which weighs in at about 70KLoC and has similar heuristics/workload challenges as does mm, would require a 430-page textbook to provide a similar level of design detail. By this methodology, RCU would require "only" 190 pages, presumably substituting its unfamiliarity for sched's and mm's deeply heuristic and workload-dependent nature.

Sadly, this data does not support the hypothesis that we can create comments that will provide understanding to people taking random dives into the Linux kernel's source code. In contrast to code that is closely associated with a specific type of mechanical device, Linux-kernel code requires the reader to possess a great deal of abstract and global conceptual/workload information.

This is not to say that the Linux kernel's internal documentation (including its comments) cannot or should not be improved. They clearly should. It instead means that a necessary part of any instant-understanding methodology for the Linux kernel include active software assistance, for example, Anthropic's Claude LLM or IBM's (rather older but less readily accessible) Analysis and Renovation Catalyst (ARC). I am not denigrating other options, but rather restricting myself to tools with which I have personal experience.

In the interest of full disclosure, this review came from a local version of my prompts that told AI to review as though it was a kernel developer who preferred vi over emacs.