4 ms·

Anatomy of a Kernel Hack

78 points by gnosis 15y ago

scott_s 15y ago
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/ http://lxr.linux.no/
- burgerbrain 15y ago
  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.
  - Cieplak 15y ago
    Wow I just learned about Ack as a result of your comment. This is a scale of magnitude better than grep -R [pattern] [directory] for searching through large codebases Thanks!
    - foz 15y ago
      Don't forget RAK, the ruby gem (works the same). gem install rak.
      - Cieplak 15y ago
        I've been using both RAK and ack for the past two days, and for some reason RAK misses things that ack catches. Probably a Cygwin issue.
- jk 15y ago
  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.
  - achiang 15y ago
    Don't forget ctags too. I feel physical pain when I see people navigating C source trees with grep.
- davvid 15y ago
  I think most gitsters (this is the kernel, afterall) would say: $ git grep foo -- '*.c'
bdonlan 15y ago
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 15y ago
  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)

78 points by gnosis 15y ago

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/ http://lxr.linux.no/

burgerbrain 15y ago
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.
- Cieplak 15y ago
  Wow I just learned about Ack as a result of your comment. This is a scale of magnitude better than grep -R [pattern] [directory] for searching through large codebases Thanks!
  - foz 15y ago
    Don't forget RAK, the ruby gem (works the same). gem install rak.
    - Cieplak 15y ago
      I've been using both RAK and ack for the past two days, and for some reason RAK misses things that ack catches. Probably a Cygwin issue.
jk 15y ago
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.
- achiang 15y ago
  Don't forget ctags too. I feel physical pain when I see people navigating C source trees with grep.
davvid 15y ago
I think most gitsters (this is the kernel, afterall) would say: $ git grep foo -- '*.c'

bdonlan 15y ago

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 15y ago
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)