How do _you_ read the linux source?

[nick]

On 2015-04-19 09:57 PM, r00nk at simplecpu.com wrote:
> 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.
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
There were a few things I did when starting to learn the kernel
1. Read Robert Love's Linux Kernel Development, I don't care how much you think
you known about the kernel read and trace the actual kernel code with this book!!
2.Read a book on device drivers and the Linux networking stack, I
read Linux networking internals for this
3. Build Linux from Scratch, this helps you understand how the system gets build for a distro
and how things get connected to the kernel/tool chain either directly or through the c library/
other libraries
4. Read Linux Virtual Memory Management as this helps with understanding the key areas of 
the virtual memory and memory management subsystems(somewhat outdated in terms of reporting
on newer kernel releases but the concepts are explained well)
5.Read The Linux Programming Interface to get used to the system calls/APIs for user space the kernel 
supports and how it is done(Chapter 5 of Linux Kernel Development also helps with this)
5. Read the Kernel wikis and documentation in the kernel tree related to areas your interested in
6. Find a area or a few your interested in and play around with them(working on this as of late)
7. Learn the best way for you to debug/trace bugs in the kernel, I learned the hard way this 
only comes with experience. This is not user space where bugs are much easier to trace,basically
understand your system calls,threading theory,how to use gdb and memory analysis toolkit,maybe
tool chain issues if working with embedded systems. The kernel is very complex in debugging everything
from deadlock to registers being written from being wrong on exact hardware can happen. Further more due
to the kernel being only a layer above hardware we very easily get bugs  that can only be reduplicated  
on exact hardware.(working on this too)
8. This a add on to 7,learn assembly for tracing bugs as this is very helpful for reading register
trace backs of oops/kernel panics if necessary for debugging.(another thing on my kernel learning list)
Hope this Helps,
Nick