this makes a lot more sense alongside the actual souce code, like in this version:

https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

I had a colleague who did some work on PDP-11 on his early career. Excited, I asked "So you were using C (language) there?" "No, it's too early" He told me, kind of dismissively. In retrospect it was obvious - The PDP11-based Unix of the Lion's Book [1] was what I had in my mind, but that was probably more like an academic pursuit than a foundational OS of commercial software.

[1] https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

The Linux kernel is unfortunately pretty far from UNIX nowadays but if you want to understand the basic concepts behind UNIX I think Lions' Commentary on UNIX is still the best resource out there:

https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

Once upon a time, programmers didn't have IDE's, Emacs, or even text editors. I'd been programming for seven or eight years before Bill Joy created vi. Each programmer and each program had its own style.

Often, a program's layout reflected the programmer's inner thoughts as he or she worked through the creation of the code. Expressions were written like a mathematician might write, with spacing and bracketing reflecting some way of thinking about the grouping of the abstractions at hand.

This is just a random routine, written around 1975, from Niklaus Wirth's PL/0 compiler for Pascal, the programming language that he created. The indenting is wild by contemporary standards:

    procedure getch;
    begin if cc = ll then
       begin if eof(input) then
                  begin write(' program incomplete'); goto 99
                  end;
          ll := 0; cc := 0; write(cx: 5,' ');
          while not eoln(input) do
             begin ll := ll+1; read(ch); write(ch); line[ll]:=ch
             end;
          writeln; readln; ll := ll + 1; line[ll] := ' ';
       end;
       cc := cc+1; ch := line[cc]
    end {getch};

Early C code too, even in the Unix kernel, was often dense and hard to understand (the kernel was under 10,000 lines back then). See Lions' Commentary [2]. Here's a small function, setfs(), line 7167 of the system 6 Unix kernel in Lion's book. In particular note the lack of indention under the for loop:

    setfs(dev)
    {
       register struct mount *p;
       register char *n1, *n2;
      
       for(p = &mount[0]; p < &mount[NMOUNT]; p++)
       if(p->m_bufp != NULL && p->m_dev == dev) {
               p = p->m_bufp->b_addr;
               n1 = p->s_nfree;
               n2 = p->s_ninode;
               if(n1 > 100 || n2 > 100) {
                       prdev("bad count, dev);
                       p->s_nfree = 0;
                       p->s_ninode = 0;
               }
               return(p);
       }
       panic("no fs");
    }

It seems obvious now that standard and consistent formatting make programs easier to understand. Why did we old timers do that to ourselves? First, short programs were easier to keypunch or enter via a teletype machine. Second, we had a plenty of time to study our code. Turn around time for a compilation, from submission to printed listing, could take 30 minutes to 12 hours.

[1] http://pascal.hansotten.com/niklaus-wirth/pl0/

[2] John Lions, Lion's Commentary on Unix 6th Edition with Source Code. https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

If you are going to study this you should also read the Lion's Commentary of the Unix 6th Edition (kernel)[0]. It provides a line by line commentary of the whole kernel (minus some of the hardware specific drivers). Xv6 is a port of the edition 6 kernel to x86 (with some minor changes).

[0] http://www.amazon.com/Lions-Commentary-Unix-John/dp/15739801...

The Lions book. http://www.amazon.com/Lions-Commentary-Unix-John/dp/15739801...