30 Linux Kernel Developers in 30 Weeks: Dave Jones

Dave Jones is maintainer of the Fedora kernel and this week shares what he's working on and what makes him tick in our latest entry in the 30 Linux Kernel Developers in 30 Weeks series. You can see all the profiles to date on our Special Features page.

Name

Dave Jones

What role do you play in the community and/or what subsystem(s) do you work on?

I'm the Fedora kernel team lead. Part of that responsibility is dealing with users kernel bugs, which ends up taking me all over the kernel. I recently gave up maintaining the cpufreq subsystem. Dealing with bugs Fedora users find (and ones I find myself) consumes all my available time.

Nothing special. Probably the same tools most other kernel developers use. A bunch of shell scripts to automate a lot of the more tedious parts of my job, like bugzilla interaction etc. I've been working on a tool to find kernel bugs a lot faster (which seems to be having quite some success [http://codemonkey.org.uk/projects/trinity/]

What do you run on your desktop?

Xfce.

How did you get involved in Linux kernel development?

I needed to build my own kernel, because none of the distros shipped one that supported something I needed. And the feature I needed was only available in the development tree at the time (which was 2.1.x at the time). I don't recall what it was, but I think it may have been something silly like VFAT. Things weren't always stable, so I got into a habit of updating regularly (by carrying the latest tarball on a zip disk from the university to home). I started sending patches for things wherever I saw something I thought I could improve. I'm struggling to remember my first real accomplishment. It may have been fixing AFFS during the 2.1.x series. There were a whole bunch of really minor things before then.

What keeps you interested in it?

A seemingly infinite supply of new bugs.

What's your advice for developers who want to get involved?

Focus on a particular aspect of the kernel that interests you, and just jump in. Start small, but punch above your weight. You won't learn a lot by fixing spelling mistakes or doing mechanical transformations guided by what checkpatch tells you. Find a problem, understand it, and try to fix it. Even if your proposed solution is wrong, the feedback you receive will be a valuable learning experience. Rinse, repeat.

I'm a strong believer in the constant need for better tools. There seem to be no shortage of new contributors to the kernel, but I feel that a lot of the tooling around the kernel (especially tools like sparse) could really use more help. Compiler/Toolchain people takes a certain rare mindset though it seems.

Another area that can always use additional help is testing. Adding new tests to test suites like xfstests, ltp, etc., would be a useful contribution that many would benefit from.