Fedora 9 'git' source kernel ??

[William Case]

On Mon, 2008-07-14 at 16:15 -0430, Patrick O'Callaghan wrote:
> On Mon, 2008-07-14 at 16:03 -0400, William Case wrote:
> > 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! 
> 
> It wouldn't be hubris if it were embarrassed.

Logically true, but a repetition of ideas shifts the emphasis

> 
> > 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.
> 
> That's not your background, that's your education :-)
> 
Only the first paragraph.  The second paragraph got snipped.

> [...]
> 
> > Bibliography 
> 
Spelling never was a strong suit.  Thank God for spell checkers -- but
missed that one.

> (Skipped the course on spelling did we :-) That's your background.
> 
> [...]
> 
> > The book that gave me the most assistance was "Computer Organization &
> > Design  The Hardware / Software Interface", 
> 
> Of course. Another classic. IIRC the Bach covers more ground than Lyons,
> but Lyons is literally a blow-by-blow account of how the thing works
> line by line. Tanenbaum is always a good read, but his approach is
> micro-kernel based and not that useful for looking at Linux (despite
> Linux 0.1 being based on Minix). This is also true of a lot of academic
> textbooks, because they want you to understand the stuff from first
> principles and some at least push a microkernel agenda (no religious
> wars about this please).
> 
> [...]

Probably all true.  Your critiques are a strong argument for exploring
the kernel myself. 

> 
> > 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 .
> 
> Understanding a kernel is a holistic endeavour, i.e. you can't really
> "start at the beginning, go on until you come to the end, and then stop"
> as the King of Hearts told Alice, so to grok any part requires you to
> grok all the other parts first (not *completely* true, but it sounds
> nice :-)
> 
Yes, I have been down that road with others.  It seems to be a bit of
academic religious proselytizing.  You are a lowly student and therefore
could never understand unless you devotedly sit at my feet and study for
years.   

I have no expectation of starting at the top and working down.  But the
kernel must have entry points and exit points.  Examining where the
major services start and end must have some value.  Besides most
learning is iterative -- one starts somewhere, understands a bit, and
keeps going around until they are back at the start ready add more.

> That said, tldp.org has some stuff, e.g.
> http://tldp.org/LDP/lki/index.html (Linux 2.4 Internals, a bit old but
> still useful). You might find http://www.linuxfromscratch.org/
> interesting as well. I've no doubt lurkers will appear to recommend
> other sources.
> 
> poc
> 
Linux from Scratch looks interesting.  Probably has everything in it
that I want to look at -- at least to start.  Thanks Patrick.

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