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 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.