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@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
