Fedora 9 'git' source kernel ??

William Case billlinux at rogers.com
Mon Jul 14 20:03:40 UTC 2008


Hi Patrick;

Thank you for asking.

On Mon, 2008-07-14 at 14:20 -0430, Patrick O'Callaghan wrote:

> Bill, I'm not too sure of your technical background so it's hard to make
> recommendations. I used to teach operating systems many years ago, and
> there were some things that always caused difficulty for students,
> because they don't arise in "normal" programming:

WARNING: What follows is some unembarrassed hubris! 

I have no technical background as you would call it.  But that has never
hindered me before. My Degree is in Arts: History, English and
Philosophy.  Even that doesn't mean much -- I went to University in the
'60s -- didn't study much.

I can say that I have made a very good living over the
years deconstructing, analyzing, reassembling and documenting logic
gaps in businesses, public policy and government programs over the
objections and obfuscations of owners, experts, professionals,
bureaucrats and politicians. In forty years of consulting, I never found
a system or entity I couldn't dig my way to the bottom of. 

I have used the same skills to learn much about Linux and computers in
the last three years.  And in the end, over all types of objections of
experienced programmers/engineers, those skills have seemed to prevail.

> 
> 1) I/O, especially interrupts. This implies at least a basic
> understanding of machine architecture.

> 2) Virtual memory systems and how they relate to real memory.
> 
> 3) How multiprogrammed systems manage lots of concurrent processes with
> seamless switching between them. The real nitty-gritty of how this is
> done is what separates the sheep from the goats. I regard it as the
> "pons asinorum" of OS theory.
> 

Since I first installed Linux three years ago, because I find the
subject of computers, operating systems, and programs personally
fascinating, I have read from cover-to-cover (without exaggeration), the
following text books:

Bibliogarphy 

"Computer Organization and Design" Second Edition : The
Hardware/Software Interface"
by David A. Patterson, John L. Hennessy

Bach, Maurice J.; "The Design of the Unix Operating System;"
Prentice-Hall Canada Inc.; Pub. 1986; ISBN 0-13-201799-7 025; DUOS

Rodriguez, Claudia Salzberg; Fischer, Gordon; Smolski, Steven; "The
Linux Kernel Primer, A Top-Down Approach for x86 and Power PC
Architectures"; Pub 2006; Prentice Hall Professional Technical
Reference; ISBN 0-13-118163-7; LKP

Stallings Ph.D., William; "Operating Systems Internals and Design
Priciples"; Fourth Edition, Pub 2001; Prentice Hall, Inc.; ISBN
0-13-031999-6; OSIDP4

Stallings William; "Computer Organization and Architecture, Designing
for Performance", Sixth Edition; Pub 2003; Prentice Hall, Inc.; ISBN
0-13-035119-9; COA

Tanenbaum, Andrew S.; "Modern Operating Systems", Second Edition; Pub
2001; Prentice Hall, Inc.; ISBN 0-13-031358-0; MOS


The book that gave me the most assistance was "Computer Organization &
Design  The Hardware / Software Interface", 

This book goes into complete, excruciating detail of how the CPU, memory
management, pipelining, interrupts etc function at the transistor, logic
gate, clocking and register level.  Far more detail than you might think
I need.  But I found after I had read through its 400 - 500 pages, even
if I only retained about 20%, huge mysteries had been solved and many
kernel questions had become trivial. And, it is always a resource I can
return to for answers to the more perplexing questions.

I have worked my way through K&R "The C Programming Language" plus parts
of C99.

Plus I keep a couple of high school level Physics and Electronics texts
near me as refreshers.  I have a couple of other texts I use for double
checking.

> None of this needs to be tied to the exact details of Linux itself, and
> in fact you can learn a lot from starting with a simpler system. In that
> sense, John Lyons' classic commentary on the Unix 6th Edition source
> code is one the best books ever written on this topic.
> 
> [Fellow oldies will recall Ken Thompson's famous comment at the start of
> the process dispatcher function (Line 2238 in Lyons' book): "You are not
> expected to understand this". :-]

As personal projects, I have dug into the functioning of two or three
essential hardware pieces and processes, taking them from the wallplug
to as far as I can, i.e bumping into kernel code.  I have documented for
myself most of what I have learned.

My current interest in the kernel is because:
a) the kernel is naturally the next thing to dig into, and,
b) reading and questioning can only take you so far; a time comes when
one has to start exploring and using the real thing.

I have tentatively used 'LXR Linux' and 'google code search' for some
very basic questions and searches.

Now that the bragging is over:  I would really like to find a logical
way to climb into the functioning of the basic kernel while keeping
blind allies and logic traps to a minimum.  I would use all suggestions
and assistance that comes my way in order to get started properly .

-- 
Regards Bill;
Fedora 9, Gnome 2.22.3
Evo.2.22.3.1, Emacs 22.2.1




More information about the fedora-list mailing list