Newsgroups: comp.os.linux
From: J.Jagger@sheffield-city-poly.ac.uk
Subject: To Linus, Lions book?
Reply-To: J.Jagger@sheffield-city-poly.ac.uk
Organization: The Internet
Date: Fri, 3 Jul 1992 09:04:24 GMT
I have a simple question and a simple request to Linus.
How did you get all your now how to create Linux?
Was hands on learning, which books/mags/articles/code
did you read? Go on Linus, give us a potted life history :-)
Also could you mail me a few lines, grouping the source code
files into chunks. I.e., which files make up the lowest most
basic layer of the OS 'onion', which ones make up the next layer?
This would make it lot easirt to peruse the code in an orderly fashion
so I can try to understand it.
Lastly (general cry to all now), does anyone know anything about
the 'Lions book'? A friend mentioned that it is an excellent
commentary on Unix, if you can get it, but that you can't. Is this
true? If so why, if not does anyone have a copy ?
:: Jon Jagger asjrbj@oak.scp.ac.uk
:: Sheffield City Polytechnic, Pond Sreet, SHEFFIELD S1 1WB
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: To Linus, Lions book?
Date: 3 Jul 92 11:35:06 GMT
Organization: University of Helsinki
In article <1992Jul3.090424.15207@athena.mit.edu>
J.Jagger@sheffield-city-poly.ac.uk writes:
>
>How did you get all your now how to create Linux?
>Was hands on learning, which books/mags/articles/code
>did you read? Go on Linus, give us a potted life history :-)
Heh. I can't let these ego-building posts go by, so I'll have to answer
it.
Linux started for several different reasons: originally just to learn
the 386, and for this the book "Programming the 80386" by Crawford and
Gelsinger is a must. At least I haven't found anything better (although
admittedly bookstores in Finland probably don't have the plethora of
books available over in the US etc).
The 386 book info has been used for all the 386 details: the lowest
level of the task-switching code, memory manager, floating point
emulations etc. It doesn't even mention the AT hardware, so for device
drivers you'll need more info, but it does contain everything on the
386/387 chips (even if it's a bit hard to read: read it through several
times before starting to look into details).
The device drivers have been written mostly by trial and error: I
haven't found a single good source of info on the standard AT hardware.
Helpful sources have been (a) the AT Technical Reference Manual (notably
the BIOS listing) (b) actual data-sheets for the 8250 etc chips used in
the AT hardware (c) other sources (mach drivers and to a lesser extent
minix drivers) (d) various books like "IBM Microcomputers: a programmers
manual", "The PC Sourcebook" etc.
Even though there are a lot of books on the AT hardware, none of them
seem to approach the information content of the 80386 books. I can't
recommend any of the sources I've used, and the best bet is probably to
have a lot of books and hope they together cover most of it.
Then there is naturally the hardware-independent parts of the kernel:
general filesystem/process/memory management. The two books I
originally used were "The Design of the Unix Operating System" by Bach,
and "OS Design and Implementation" by Tanenbaum. Tanenbaum's book
should be read a couple of times: ignore the details (especially about
minix), but get the general picture clear. The Bach book has a few nice
algorithms in it, and I'd suggest reading them too: many of the actual
ideas on how something could be implemented came from that.
Still, OS design is mostly common sense: it doesn't need complicated
algorithms like a compiler does or similar. A lot of thought, careful
programming and some good decisions. And unix is a very simple OS
really: I first came in contact with it 2 years ago when I did the
"C-kieli ja unix ohjelmointiymp{rist|" course in the fall of -90. By
early -91 I had bought a PC, and linux v0.01 was ready in August -91.
That wouldn't have been possible with some other systems I could mention
(VMS.. arghh).
The most difficult parts are:
- device drivers: you can go crazy trying to find why something doesn't
work on some machines (especially if you can't even test it out).
- filesystem: trying to make it clean and well designed, as well as
getting rid of all race conditions. The current linux vfs layer seems
to work well enough, but my original design wasn't too good. Rewriting
big parts isn't fun when something works.
The kernel proper is pretty simple in fact, although you have to keep
track of a lot of things. The memory manager has also survived pretty
well all the changes, and although I'll have to change it to use
different page directories for different processes some day it will
probably look pretty similar even after that.
>Also could you mail me a few lines, grouping the source code
>files into chunks. I.e., which files make up the lowest most
>basic layer of the OS 'onion', which ones make up the next layer?
>This would make it lot easirt to peruse the code in an orderly fashion
>so I can try to understand it.
Hmm. To get a good general idea of the different pieces, I'd suggest
reading linux/*/*.c - all the memory management sources, the normal
kernel sources and the vfs routines. They are pretty modular: you can
generally understant linux/fs/*.c without having to understand the
kernel and vice versa (for a general picture, that is. For the details
you usually have to read it all).
The linux device drivers (linux/kernel/chr_drv and linux/kernel/blk_drv)
are a pain to read: they don't actually give you any more info on the
kernel itself, so reading them is only needed if you really want to know
how a block is loaded into memory etc. Similarly for the math-emulator
(linux/kernel/math).
The special filesystems (linux/fs/minix and now linux/fs/ext) can be
read if you are interested in the actual lay-out of the disk, or if you
want to see how some of the fs races are handled. Note that most
race-conditions are handled directly by the buffer-cache routines or the
vfs layer, but some races are inherent to the actual fs implementation
(renaming a file etc).
Linus