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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
