Anatomy of a Kernel Hack

[scott_s]

Rather than doing recursive greps, I think that LXR (The Linux Cross Reference) is a much better way of exploring the kernel: http://lxr.linux.no/

[burgerbrain]

More generally, Ack is great for doing "recursive grep's" on source code. By default it does a pretty good job of only listing matches from filetypes you're likely to care about.

[davvid]

I think most gitsters (this is the kernel, afterall) would say:

    $ git grep foo -- '*.c'

[jk]

cscope (kscope if you want GUI) will be easier if you have a copy of kernel. lxr is useful when you do not have a local copy of kernel.

[bdonlan]

For what it's worth, it's usually not necessary to recalculate the bogomips value - it's only really used for usleep(), a routine used to sleep for short intervals (on the order of microseconds) to wait for hardware to stabilize. Overestimating slightly is not a problem - but even then, the cpufreq driver actually does scale this up and down as the CPU speed changes.

[mjg59]

These days. In the (pre-ACPI) past some machines would change CPU frequency on AC events in system management mode, without any real way for Linux to know that it had happened. If you booted on AC and then went to battery then you'd probably be ok because kernel delays would just get longer, but booting on battery and then going to AC could result in these timeouts being significantly shorter than the hardware required. Once Intel actually documented their Speedstep implementation, and once ACPI gained support for expressing CPU performance states and notifying the OS, this mostly went away. But it was a real issue in the past.

(Nowadays we just have to deal with vendors who've decided that their firmware can do a better job of CPU power management than the OS and change frequency without telling us, but that's Enterprise so it's ok)