From: sync...@sbcs.sunysb.edu (Synchem proj acct)
Subject: VERY DETAILED history of Linux in its early days
Sender: use...@sbcs.sunysb.edu (Usenet poster)
Organization: State University of New York at Stony Brook
Date: Fri, 2 Oct 1992 00:54:43 GMT
[Why is it always seem to be the case that whenever I post news,
our news system breaks? Anyhow, this is my 3rd attempt, I hope this
Partly due to my curiosity on how Linux kernel works at the inner most
and partly due to my wish to find out the kind of things
one has to decide when writing an OS from scratch, I wonder if some
kind soul can answer the following for me:
1. Does anyone still have a copy of Linux 0.01, or is it 0.11,
when all Linux does was switching two processes printing AAAA, BBBB...?
Or some very earliest version of Linux?
2. An as detailed as possible description of things that are gradually
added to Linux since when it can only print AAAA, BBBB? And the design
decisions? I guess up detailed descriptions would be needed for only
up to 0.12. Things after that can most likely be found in textbooks.
3. What are the considerations of in deciding what goes into kernel
and user space?
I guess what I'm looking for are concrete details,
using Linux and 386 as examples, not those things one can find in textbooks.
I hope this would be a start of documenting Linux for those of us aspiring OS
From: torva...@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: VERY DETAILED history of Linux in its early days
Date: 2 Oct 92 09:03:25 GMT
Organization: University of Helsinki
In article <1992Oct2.005443.18...@sbcs.sunysb.edu> sync...@sbcs.sunysb.edu
(Synchem proj acct) writes:
>1. Does anyone still have a copy of Linux 0.01, or is it 0.11,
> when all Linux does was switching two processes printing AAAA, BBBB...?
> Or some very earliest version of Linux?
The AAABBBB version certainly doesn't exist anywhere - that was long
before I thought it was worth it to make it freely available. While
0.01 wasn't much, at least it *did* work as a simple unix clone.
The oldest version that I was able to find with some fast ftp'ing was
the 0.10 version of linux - and that most definitely did work (that's
about the time when I tried to autodial my harddisk, and lost all my
minix files...). 0.10 had some serious problems (no floppy driver if I
remember correctly, and a bad bug in the buffer code), but it already
ran gcc etc happily. And it's only 130kB in size - the current kernel
is >600kB (but new drivers are a big part of that..)
>2. An as detailed as possible description of things that are gradually
> added to Linux since when it can only print AAAA, BBBB? And the design
> decisions? I guess up detailed descriptions would be needed for only
> up to 0.12. Things after that can most likely be found in textbooks.
I've promised to write down what I remember (which isn't much) some time
ago, but I haven't got around to it yet (writing not being my favourite
Design decisions: none. Linux wasn't designed - it grew over a period
of time, and I'm still impressed by how few bad decisions I've made so
far (I've had to rewrite a lot, but nothing *really* broken). There
were a couple of guidelines: keep it simple, and do it the easy way. On
the other hand, I started with a pretty good idea of what I wanted, and
I had the truly basic thing (multitasking) going at the very beginning.
- get into protected mode [Feb-Apr]. This isn't easy - especially if
you are learning the assembly language and the quirks of the PC
architecture as you go. This took several months (I made some small
trials in this direction even before I got minix).
Simple screen-IO came up here - mostly because that was the only way
I could announce any kind of success. Poking a few long-words to
screen memory and having a delay was the easiest way to show that the
program had gotten enywhere.
- multitasking. Getting a timer interrupt to work, and to switch
between two tasks. This is where the first simple tty driver came
into play, and when I printed out the AAA BBBB things. No memory
management, no frills, just two different threads that got switched
around by the 386 task-switching primitives.
- basic drivers [May-June]. Mostly getting interrupts to work,
refining the tty driver, getting the serial lines working (hardcoded
to 2400bps until version 0.10 or so, because that was/is all I have).
I used "linux" mostly as a terminal emulator by this time: it was
written 100% in assembly, and did terminal emulation by having two
threads: one read the keyboard and wrote to the serial line, the
other read the serial line and write to the screen.
By this time I had gotten confident enough about the system that I
could start using C - but I think the console driver was in assembler
until version 0.11 or so. I still had no harddisk drivers, no memory
management and no filesystem.
- basic harddisk driver, minix-fs, buffer cache [June-July]. These
were somewhat intertwined: I needed all of them to be able to test
things. The harddisk driver was first, then a simple buffer cache,
then some basic fs routines. But they all got changed as other parts
- basic system resources - mm, system calls, and refinement of the old
parts [July - Aug]. This is where I started writing small linux
programs to test out things. Mostly they were still hard-coded into
the kernel - the system was still not up to a real fork/execve. I
got there slowly, and eventually was able to port the minix shell to
linux. Glorious day (but I've forgotten when this was :-).
- basic enhancements - [Aug-91 - Sept-92] getting gcc to work (which
really needs a working buffer cache..), porting basic utils, making
it all available.. Getting X running, etc :-)
Note that the above is a very much simplified history, and the dates are
only "so-so" - they can be off by a month or two. Also, the
developement wasn't as modular as the above would have you believe:
that's just a rough timetable. And even when I first released it, 0.01
never really worked: it was just a source release (September-91?).
>3. What are the considerations of in deciding what goes into kernel
> and user space?
As much as possible goes into user space, as long as it's not too much
of a bother. If something gets much easier or cleaner (387-emulation)
by being in the kernel, then so be it.