How could early UNIX OS comprise so few lines of code?

Question

I start my journey to become a hardware / software specialist with an internship in two weeks time and decided to start studying the C language early.

I came across this video, Learn C Programming with Dr. Chuck (feat. classic book by Kernighan and Ritchie), that claims the UNIX OS was written in only 13K lines of code. Which seems a remarkably low number.

Is it true, and if so how did they manage it? Seems completely antithetical to the monolithic monstrosities we know operating systems to be today.

Answer 1

If you look at the code in the modern Linux kernel, you will find that most of the code is in the device drivers. There are tens of millions of lines of code to support everything imaginable -- the networking cards in 1990s DEC Alpha workstations, the soundcards in late 1980s ISA IBM PC-compatibles, modern 64-bit ARM tablets, all the USB devices, and so on.

On top of that, we have dozens of file systems, support for many different kinds of networking protocols. There are multiple different schedulers -- not just for processes, but block IO and network transfers. And so on. In fact, the feature variety and hardware drivers make up the great majority of Linux code. Linux, before all these features and bloat were added, as originally released as a crude kernel for 386 machines, was also measured in tens of thousands of lines of code.

I've written a small multitasking kernel, for an embedded application, so I feel qualified to say: it really isn't that big of a job. The basic UNIX design of processes and file system is a structure that has several interworking parts, so it's delicate and finnicky. But it's not ultimately that complex.

Basic memory management takes a few hundred lines. Implementing basic processes takes a few hundred lines. A basic file system takes a few thousand lines of C code. Device drivers depend on the complexity of the device, but can be quite small. You just need drivers for a terminal of some kind, and a disk of some kind.

That will give you the core to load binaries, execute them, and give them some system calls for reading/writing files. That's about all the original UNIX provided. But then you will want networking and fast algorithms for disk caching. It rapidly starts adding up.

Answer 2

Yes, and you can buy it in a fully annotated book and have your own copy to peruse, should you be a skeptic:

Lions, John; (1996) "Lions' Commentary on Unix", ISBN 978-1573980135

I have had a copy on my shelf for some time, even though I ported unix to several systems prior to the publication and was familiar with the source of several versions by then. Still an important reference book for learners and gurus alike.

Answer 3

That's reasonable.

The first Unix was written in assembly language for the PDP-7 and PDP-11, which had some 16 kB system memory. You can't run a large OS on that! The first versions of the C-based Unixes were built after 1970, when memory was still horribly expensive.

Only in 1980 did 32-bit computers begin to take over in great numbers, and even those started typically with some 4 MB of RAM or even less. This is very similar to today's 32-bit microcontrollers (such as the STM32 or ESP32), for which there exist Linux kernels with a compiled size of about 1.5 MB. They contain more than what the original Linux used to have, but it's reasonable to think that 13,000 lines of C code can get a binary on the order of 500 kB to 1 MB.

Answer 4

Is it true, and if so how did they manage it?

Yes, it is true, as proven by the book linked in Brian's answer.

As to how they managed it: computers are, as a rule of thumb getting more complex over time. Turning that around means that in the past, computers were on average simpler than today. The PDP11 reference manual has around 200 pages (with the PDP-11 being considered the smallest machine having been able to run Unix); the 8086/8088 manual clocks in at 100 pages for the CPU itself but takes 800 in total to describe additional I/O processors and other relatively important parts of the architecture. The 1993 manuals for the Pentium Family already span around 1900 pages, and well past 2000 for the IA-64 docs.

This means all aspects - the hardware itself (from CPUs over the general architecture to ancillary modules like GPUs, or even math co-processors back in the foggy past), but also the software (i.e., features expected by programmers or users), the networking, and so on and forth, got ever more complex; and at the same time, users expected the OS to handle all of that in lieu of the applications ever more.

Many of these complexities scale up exponentially in that adding one feature in one of those areas influence many of the others, thus leading to additional lines of code in many places.

So even if a completely new OS today had zero baggage in the form of backward compatibility, or having to support large numbers of historic hardware devices, it would be much larger than in the distant past simply because the system architecture (CPU, GPU, I/O, RAM, and other low-level modules, together with busses and so on) is vastly more complex on even small machines today than it was in the past.

(As a little bonus: you can run a PDP-11 emulator with the Unix v6 kernel in your browser of choice (including access to cc so you can compile programs). It doesn't do much for this answer, but I find it awesome enough to include it. Here is the deep link to the actual JavaScript code of the emulation. Imagine how long this code would be for a modern CPU...)

Answer 5

An additional reference point, Minix:

MINIX 1.0

Andrew S. Tanenbaum created MINIX at Vrije Universiteit in Amsterdam to exemplify the principles conveyed in his textbook, Operating Systems: Design and Implementation (1987). (Despite sharing a name, it has no relation to the older MINIX from Digital Systems House, Inc. based on AT&T Unix code.)

An abridged 12,000 lines of the C source code of the kernel, memory manager, and file system of MINIX 1.0 are printed in the book. Prentice-Hall also released MINIX source code and binaries on floppy disk with a reference manual. MINIX 1 was system-call compatible with Seventh Edition Unix.

(emphasis mine)

Answer 6

Early time-share systems could not hold two programs in memory at once. All task switching was accomplished by swapping a program's entire state out to disk. This would obviously be slow by modern standards, but the use of line-based I/O meant that a task switch would often only be necessary when a user finished typing a line of input. Further, task switching would use dedicated areas of the hard disk so as to avoid directory look-ups or other such overhead.

Understanding this is critical to understanding the design rationale for fork(). If a computer is running task #4, and it needs to give task #5 a time slice, it would need to save its current state to slot #4 on the hard disk, load task slot #5 from the hard disk, and resume execution. If a program running task #5 wanted to fork(), and there was no task #6, it could add slot #6 to the list of active tasks, and save its state to slot #6, and resume execution without loading a task from the disk. Forking a task was thus faster than doing a normal task switch, since it only required saving the current state and not retrieving an old one. It was also easier than creating a new task with specified parameters, since doing that would require building an image of what the new task should look like, while forking could exploit the already existing task as a model.

A lot of the complication surrounding Unix memory management today stems from the need to have multiple tasks in memory at a time, with the usable memory divided up dynamically among them. If it had been acceptable to simply give each task a fixed allocation which it could use as it saw fit, as had effectively been the case in the full-RAM-swap era, things could have been much simpler but it would have been necessary to let the system know, before running a program, how much memory it should be given. Such restrictions existed in the Macintosh OS which I used a lot in the 1980s and 1990s, and while they were at times annoying, they offered some advantages which might still be nice today (e.g. if one could control how much memory was available to different browser tabs).

Answer 7

Unlike previous OSes, UNIX provided the pipe facility to allow you to combine the functionality of many small programs.

Ex. ls | grep ... | sort ... | more

Before that, every command-line program had to support the full suite of additional functionality like search, filtering, paging, etc. This UNIX/Pipe approach allowed for greater reuse and much less code. This is explained and simulated in this video: https://www.youtube.com/watch?v=3Ea3pkTCYx4