On Wed, Sep 26, 2012 at 8:33 AM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > > in my online travels yesterday, i ran across this gem, "Linux Kernel > Crash Book": > > http://www.dedoimedo.com/computers/crash-book.html > > and am now wondering about what would constitute a reasonable (and > minimal?) list of canonical kernel debugging tools. > > first, while the book above covers Linux Kernel Crash Dump (LKCD), > the author freely admits that it's been pretty much obsoleted by the > more recent and flexible kdump, so there seems to be little value in > digging into LKCD (or, in my case, adding any coverage of it to a > kernel debugging course, which i am currently designing). > > next, someone else's course i'm teaching next week has a kernel > debugging chapter which opens with netdump and diskdump before moving > onto kdump and kexec, but those earlier utilities are *also* > deprecated these days, > > http://serverfault.com/questions/181554/how-should-i-capture-linux-kernel-panic-stack-traces > > so i would be tempted to skip any coverage of netdump and diskdump in > favour of additional and more advanced coverage of kdump and kexec. > > along those lines, i'm just digging into ftrace and was wondering if > it in any way obsoleted systemtap, but i've heard from more than one > source that while ftrace is allegedly more powerful, systemtap still > has its place and is worth talking about. > While learning ftrace I found there's little good documentation for ftrace. Ftrace is huge and very flexible, you can do lot more than just trace your functions. I firmly believe ftrace + perf should be consider like a serious debugging technique. Regards, Ezequiel. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
