Latest Linux kernel source:

     39051  certs    0.0%
     40404  usr      0.0%
    164228  init     0.0%
    240426  virt     0.0%
    250265  ipc      0.0%
    459021  io_uring 0.0%
    664443  rust     0.1%
    979555  samples  0.1%
   1885010  block    0.1%
   2849606  scripts  0.2%
   2953164  security 0.2%
   3609139  crypto   0.3%
   5165331  mm       0.4%
   7156454  lib      0.5%
  12419586  kernel   1.0%
  33047417  net      2.5%
  39916290  include  3.1%
  43223905  fs       3.3%
  45000780  sound    3.4%
  54987535  tools    4.2%
 107971048  arch     8.3%
 943527384  drivers 72.2%

Based on byte count (total 1,306,550,042 bytes in the above).

arch seems pretty essential and it's still at 107m. hardware is complex, no way around it.

I'm not familiar with linux, but is arch platforms support for a bunch of different archs - x86, x86_64, arm, arm64, and many more come to mind.

As sibling pointed out, to be fair you'd want to somehow restrict arch/ down to one only architecture.

FreeRTOS on the other hand is just two C files.

And a proper secure microkernel much less.

With virtual memory and demand paging, memory management (done efficiently) becomes a much harder problem, too.

Unix V7 had virtual memory, at least, I can remember the PDP-11 disk unit throwing itself around violently when somebody started nroff.

> the PDP-11 disk unit throwing itself around violently when somebody started nroff.

That was the overlays… the early days substitute for the virtual memory proper. If I remember correctly, the first PDP-11 to have the true virtual memory and a MMU was PDP-11/70 which had 18-bit wide hardware addresses.

The 11/70 had a 22-bit wide memory bus and an 18-bit wide unibus which was mapped to the high 256kb of the 4M physical address space.

You are correct. I have long forgotten about the mapped memory and was thinking about Unibus device registers having long 18-bit addresses. The 11/70 also had separate instruction and data spaces which did not exist in earlier models.

Many years ago the team I worked out got some shiny new Sun 4 machines and we soon ran out of disk space - solution was to plug a cabinet full of a few old huge disks that I think came from some kind of ancient mini into a Sun 3 and then NFS the new storage onto the Sun 4s.

It was truly bizarre to watch the cabinet judder and shake as we accessed stuff - I think there were only 2 disks in it and it was mostly full!

Although the 11/70 had primitive mmu support, V7 ran on the /45 and /55 and did not use anything besides I/D separation.

They also didn't care nearly as much about performance.

Or to be more precise, they had very different trade-offs to make. Back then, you could have a system call and context switch for every read and live with the overhead.

Today we have something like io_uring.

Back then, fitting in RAM was a big problem: The PDP-11 (the first kind of computer to run Unix, as opposed to UNICS) had a 16-bit address space, which gives you 64 K of RAM if you ignore the fact peripherals were memory-mapped and so took addresses away from actual memory. Later models had split I+D, or separate address spaces for Instructions and Data, but that's still only 128 K.

https://gunkies.org/wiki/PDP-11_Memory_Management

Later models could address 18 (256k) or 22 bits (4Mbytes) of memory.

Still restricted to I+D of 128K mapped in at any given time, plus your 8K of I/O space for bank 7.

I'd guess that back then system call overhead was lower than with modern CPUs with deep pipelines, speculation and their vulnerability workarounds.

I'm thinking most stuff was designed around single core performance. Lots of drivers had big'ole gigantic locks which really killed multi processor performance. These days with modern CPUs with a ton of cores the complexity has increased greatly.

It wasn't lower. But people put up with it.

Because they had to; there just wasn't a viable alternative

For sure, and up until the mid-to-late 80s RAM speeds were higher than processor speeds. So approaches to architecture were totally different.

Most minicomputer class processors were sewn together from multiple chips and transistors; even their register sets for the CPU were often not dissimilar from main memory. Texas Instrument's minicomputer (and later microcomputer) architecture even just put registers in RAM. In the microcomputer world, the 6502 got around having a very small register set by just having a 256-byte "zero page" with slightly faster cycle access than regular memory.

There was no need for complicated cache hierarchies. Relative cost of a context switch or interrupt or transition from user space to kernel etc. was way lower than now.

And the users of the system were by and large trusted. Security was more of a suggestion.

We did care about performance because 1 MHz was slow even back then and data bus were slow too. However we had to care more about memory size because we couldn't fit much in a few kB or 1 or 2 MB for huge machines. Finally, compilation time for substantial programs were... substantial! You could play games as in that sword fighting xkcd.

They also did't care that much about

* unit testing

* framework boiler plate

* testing pragmas

* mockups

If you’ve read any of the code you’ll also know that early Unix was full of security vulnerabilities. Eg. Statically allocating fixed buffers and not checking input sizes.

I’m all for appreciating simplicity, but let’s not pretend we haven’t progressed since then.

Not only early Unix; look at the original inet_addr implementation [0]. It accepts not only "0x" but also just "x" as the 16-base prefix, it doesn't really care about the numbers overflowing, and it parses 09 as equal to 011 (which is decimal 9). And the less said about the coding style, the better.

[0] https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/...

There were also a lot of practical limitations on the hardware that need to be recognized. These weren't devices that could store megabytes of data for code or memory. Not only that, but the compilers were also a lot dumber (by necessity). So, optimizations you'd normally leave up to the compiler (like inlining) you instead did by hand.

This part is frequently lost on people. Bell labs developed a multi-user operating system that supported multiple people logged in at the same time on a machine with 64 kilowords (144kB) of storage.

Later development was done on a machine that supported a max of 4MB of memory and had to allow for hundreds of simultaneous logins. Keeping the code compact was a high priority, even over usability in some cases.

Unit testing doesn't account for many lines in the Linux kernel. I see 33 test suites.

    $ find include/kunit/ -type f | xargs wc -l --total=only
    2418
    $ git grep -lE '^kunit_test_suites\(' | xargs wc -l --total=only
    17838

But modern Linux is only the kernel. Early unixes included the userland as well which creates a different balance in types of code.

In fact traditional unixes still do, like FreeBSD. Linux is the odd one out with this separation. I think it happened because GNU was not very successful with Hurd but they made great userland so "Linux" became kinda a combo. And for Linus the userland was never really in scope anyway.

I'm only speaking from impression, but I think early Unix's userland is probably comparable with busybox in terms of code size and features.

I’d be surprised if early Unix userland wasn’t even more barebones than busybox.

It sure was. But so was the kernel itself. I don't think the balance between them changed a lot over time.