Linux Kernel Development Tips and Tricks
This page captures some of the more obscure and poorly documented kernel
development practices and advice for working with the community.
I'm not one of the uber-developers and I have made pretty much all the
mistakes one can make with the community and I'm still standing, and
getting paid to work with them. I'm just trying to say its not so
hard to do and if you are interested in kernel development don't be shy.
My collection of tips and tricks is not an order set and somewhat
random. Feel free to send corrections or tips I really should
include.
DebugFS
Debugfs is cool and easy to use. However; nowhere in the
documentation is the tit bit of info on how you need to mount this
virtual file system :(
Ruining Sparse
Sparse is a really nice lint-like code scanner that will catch some
common errors. When I was first told to run Sparse I googled for
it and came up with a mountain of crap none of which was helpful.
It was frustrating and embarrassing to find out that it was documented in
the kernel documentation directory
Sparse is documented in the kernel/Documentation/sparse.txt
Use Sparse.
Checkpatch is your Friend
Check patch is a format checker that if you, mostly, pass its
examination of your work then you can be somewhat hopeful of not
getting too many replies about your lack of attention to expected norms
of kernel formatting and patch submissions. Using check patch is
documented in the kernel/Documentation/SubmitChecklist file.
If you haven't read the following 3 files in a while you should read
{SubmitChecklist, SubmittingDrivers, SubmittingPatches}. Actually
these should be reviewed at least once a year.