How do _you_ read the linux source?

[r00nk at simplecpu.com]

The following question gets asked a lot, "I know C, but reading the
kernel source is hard, what should I do?" and the common response is "ctags."
It's a lot like asking "how can I build a house?" and receiving the response
"screwdriver."
	There is obviously more to it then learning C and installing ctags.
As a newbie myself, I recently had to overcome this problem, Here's what I
did:

	First, I asked myself 'who understands the linux kernel?'. Linus was
the obvious answer, so I hunted down anything that he wrote. I found that he
had an autobiography, so I picked up a copy and read it. In it, I learned
about the foundational 'open, close, read, write, fork, exec' system calls.
	Second, I decided to try to write my own kernel. In writing it, I
learned how central the filesystem was to unix, I learned the significance of
interrupts, I wrote a few drivers, and I ran into (and sometimes got past) a
few nasty deadlocks.
	Third, I subscribed to the mailing lists and begun to read through them.
I got caught up on the way things are currently done, and I found and read
the
way linux approached the problems that I had already become familar with.

	Ok, lets take that and break it down;

	First; Find if someone has done this before. If they have, find out
how they did it.
	Second; If you can, try praticing it or solving said problem yourself.
	Third; Now that you have the foundations, figure out how its currently
being done.

	Now for the important part. It's an algorithmn. See:

	if(someone has done this before)
		figure out how they did it;
	if(we can try)
		try to solve it ourselves;
	figure out how it's currently being done;

	And that's how I usually solve a problem. _However_, I didn't come up
with that algorithm myself. I had a programmer friend who was very
skilled. He
always seemed to do what others thought to be impossible.  One day I asked
him
how he did it, and he said "well, I look if some one has done it before,
then I
try it, then I look at how people do it now." I imitated this, and it lead me
to become a much better programmer.
	My point is this, I learned how to do things by learning the thought
process of someone who could. I'm not saying that that example is the best
way,
or even a good one. I'm saying that learning the way others think and
approach
problems is key to success.

	The problem a lot of newbies are having is in 'separating the trunk
from the leaves.' So my question is this: Experienced kernel developers, how
do _you_ read source code? How do you separate the trunk from the leaves?
What do you do when you read code you're not familiar with? How do you learn?
What's your algorithm?

	I mean obviously it might change on the context, or you might have
more then one way. But still, any peek into the way you've learned to
approach problems is incredibly valuable.

	Anyways, thanks for your time.