| > Seeing someone's thought process when debugging something like a kernel would've been really useful. The first thing when doing a kernel is don't be clever. Suboptimal isn't just good--it's preferred. Linear searches are fine. Shell sorts are fine. Arrays are fine even if you have to recopy them a lot. Hashes are too complicated. Trees are too complicated. Randomizing things is too complicated. Until your kernel needs to scale, the "suboptimal" ways are more understandable, and, as a bonus, they sometimes are more optimal as they require less up front overhead. The second thing is "replace pieces". Because you weren't clever, you can rip out and change chunks with relative ease. It's not "proper", but, if you're on a deadline, sometimes swapping some component and having the bug go away is good enough. Just realize that, if a bug goes away randomly rather than because you understood it and killed it, you have planted a time bomb likely to blow up in your face at the worst moment. :{ The third thing is "hypothesize and THEN test". This drives me crazy with junior folks. If I had a nickel for every time I got the response "I dunno" in reply to "Okay, why did you think doing X would fix things?" I would be a rich man. This is the piece that makes debugging a kernel hard. You have multiple layers of abstraction, and the bug is probably 3 layers away from the thing that triggers it. Something which I tend to use more for things like kernels than "normal" programming (whatever that means) is that I religiously check and assert on my data structures even at great performance penalty. Having a data structure blow up immediately is far better than soldiering on and getting the malfunction after everything is scrambled. Something which I am becoming increasingly religious about is that time is an input to my functions that operate on "external" inputs (button presses, RF events, USB events, network packets, etc.). It's a pain sometimes, but when you need to debug something subtle, it is really nice to be able to replay things exactly. And, a final piece of advice, learn your tools. GDB, for example, is amazingly powerful. Unfortunately, I only seem to learn more about it after the fact. :( I do something really stupid and someone asks "Why didn't you just do <mumble foo mumble> in gdb?" and my response is always "Because I didn't know about it." |