On Wed, 19 Sep 2007, Suresh Jayaraman wrote: > On Fri, 2007-09-07 at 12:15 -0400, Robert P. J. Day wrote: > > > i'm putting together a short tutorial on this topic, so i wanted > > to be fairly complete but not repetitive. at the moment, if i had > > to keep things really short, here's what i'd explain: > > > > 1) using plain "gdb" with vmlinux and /proc/kcore to at least > > *examine* values in a running kernel, > > > > 2) kprobes > > > > 3) systemtap > > I think it won't be complete without discussing atleast one of the > crashdump mechanisms e.g. kdump + kexec and analysing with "crash". > Also, you can touch upon NMI Watchdog which really helps in case of > Hard lockups. i was already adding kdump + kexec to the mix. also LTT-ng. what i'm trying to avoid is having overlap or redundancy among the topics. (for example, there's no point in covering LTT when there's already LTT-ng, that sort of thing. and some coverage of the new linux markers stuff would be good, too, if i can squeeze it in.) > A reference to debugging options in the "Kernel Hacking" section > while configuring the kernel would help too. e.g. > CONFIG_DEBUG_SPINLOCK etc. i had already pencilled that in to an earlier course that i'm writing. i don't consider that stuff so much "debugging" as real-time validation, if that makes sense. if i can avoid it sounding like marketing (since i doubt many readers of this list are potential customers), i've been a linux and OSS trainer for a number of years, and i've decided to start a new venture that focuses on what i call "crash courses" -- really intense, 1-day corporate courses that target a specific topic. so when i say i want to put together a 1-day course on kernel debugging techniques, i have to be ruthless in terms of selectivity, and include only those topics that have obvious value. no fluff, no filler. (heck, a course on systemtap alone could easily fill one day so the best i could do here would be a basic intro.) so that's why i was trying to be selective -- i was after a basic list of kernel debugging tools that had value, that didn't overlap and that covered the spectrum from simple to sophisticated and that would nicely fill a day of instruction. and that's my story and i'm sticking to it. :-) rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
