Kernel space: Merging drivers early

There is little in the way of a downside to making drivers available earlier. Since they are self-contained, they generally don't cause problems elsewhere in the kernel. As long as reviewers are keeping an eye out for security problems, which could lead to an unsuspecting user's box being compromised, there are not many ways for a driver to negatively impact the kernel as a whole. User space interfaces via ioctl(), sysfs, or other means also need to be closely examined as they will have to be maintained as part of the kernel interface.

Along the way, much grumbling was heard about checkpatch, the perl script that complains about various stylistic problems with a patch. Notably absent from the list above is any kind of requirement that checkpatch errors or warnings be handled. The main complaint against checkpatch is its checks for line length; the resulting "fixes" to kernel source sometimes leave much to be desired. While it is generally agreed that too many overly long lines can result in code that is difficult to read, exactly what constitutes such a line tends to be an aesthetic judgment. Slavish adherence to a fixed number of characters on a line in order to appease checkpatch is clearly seen as a problem.

To some, this makes checkpatch less than useful, bordering on dangerous to readability. Torvalds stated that he has considered removing it from the kernel tree on more than one occasion. Human judgment is required to interpret the warnings from checkpatch and sometimes it is not being applied. On the other hand, Ingo Molnar gives an impassioned defense of the tool:

Based on this first hand experience, my opinion about checkpatch has changed, rather radically: i now believe that checkpatch is almost as important to the long term health of our kernel development process as BitKeeper/Git turned out to be. If i had to stop using it today, it would be almost as bad of a step backwards to me as if we had to migrate the kernel source code control to CVS.

Molnar goes on to outline the pros and cons of checkpatch, all of which stands in stark contrast to some of his earlier complaints about the tool.

For most drivers, the path into the kernel has been made a lot easier. This will have the effect of getting working, or mostly working, drivers into the hands of users more quickly. More importantly, it will also get the code into the hands of the Linux kernel community faster. The likely result is a fully working, cleanly coded driver sooner than it might have happened in the past. An already quick turnaround for hardware support in Linux may have just gotten faster.