Linux Kernel Dev Notes

The Kernel Commandments:

  • Thou shalt not sleep neither call kmalloc(size, GFP_KERNEL) in interrupt context.

  • Thou shalt use rmb() and wmb() before or after iowrite() or ioread() to instruct o’slave compiler to produce the side effects, when you need them.

  • Dereferencing a __user pointer is strictly forbidden, even to the bravest and enlighnened kernel developer.

  • A good C developer always cleans up its garbage, in reverse order.

  • Thou shalt synchronize an RCU data structure before writing to it

  • Thou shalt use floating point ops only in a special fpu context

  • Thou shalt never use sysfs API directly, unless he works deep in filesystems. Always use groups, or you will create a race condition and made fun of.

  • Beware of the scary spectre when reading memory indexed by an user variable. Use array_index_nospec() or speculation_barrier() when necessary.

  • Add “Fixes: <commmit-id> (“<commit-message>”)” tag if you are fixing a previous patch

  • Thou shalt use devm_* functions whenever possible, as they are liked more

  • Before touching a per-CPU variable, thou must disable preemption or interrupts using get_cpu_var() and release it with put_cpu_var()

Useful commands

Get who owns what in the kernel. –nogit-fallback will not output developers who modified the file:

./scripts/get_maintainer.pl -f <path> --nogit-fallback

When building your module, ensure you have warnings enabled (1, 2 or 3):

make W=1

Always checkpatch before thinking about sending a patch:

./scripts/checkpatch.pl -f drivers/staging/your-driver/your-file.c

Also run coccinelle, a static code analysis tool:

make coccicheck MODE=report M=drivers/staging/iio/

Generate the ctags so you can jump to definitions in your code editor:

make tags
# For emacs gtags:
make TAGS

Sending a patch

Make your comifications (after running checkpatch and coccinelle):

# Make sure your ~/.gitconfig is correct
git commit -s

Generate patch:

git format-patch -1 HEAD
# For a series
# git format-patch -v1 --cover-letter staging/staging-next -o outgoing/
scripts/get_maintainer.pl outgoing/0001-your-patch-name.patch
# Modify the patch
git send-email \
  --to="gregkh@linuxfoundation.org" \
  --cc="linux-staging@lists.linux.dev" \
  --cc="linux-kernel@vger.kernel.org" \
  outgoing/0001-your-patch-name.patch

Videos

Greg explaining release cycle and patch flow from mailing list to stable:

Linus talking about linux:

https://www.youtube.com/watch?v=WVTWCPoUt8w

Some very interesting topic from Linus:

  • Software is almost never designed, because rarely anymody knows exactly what they want to do, or they don’t after some time. Instead, software evolves over time as many interests and goals shape the project as it goes.

  • How much GPL is important for ensuring the evolution of linux. If comanies (which are greedy) make modifications and keep them to themselves, then linux would never be able to grow and evolve the way it does with GPL. Same for closed source software, the company that manages the software limits its potential and evolution.