Merging drivers early [LWN.net]

By Jake Edge
February 27, 2008

Drivers tend to be a world unto themselves, with bugs only affecting a subset—often a tiny subset—of kernel users. Until a driver gets merged into the kernel though, anyone wishing to test it, or help clean it up, has to jump through some hoops. To try and help reduce those barriers, Linus Torvalds and others have been advocating early merging of drivers; getting them into the kernel and incrementally improving them from there.

This policy of early merging of drivers is not universally embraced, with a recent remote DMA (RDMA) ethernet driver, which lives in the infiniband tree, getting singled out. Based on the problems he observed in the driver, Adrian Bunk asked: "Is it really intended to merge drivers without _any_ kind of review?" This was, perhaps, an overly dramatic question as the driver has undergone review, but not all of the changes have been reflected in the mainline version. There is still work to do, as Infiniband maintainer Roland Dreier points out:

Just to be clear, this driver was reviewed. Many issues were found, and many were fixed while others are being worked on.

It's a judgment call when to merge things, but in this case given the good engagement from the vendor, I didn't see anything to be gained by delaying the merge.

It is a sentiment shared by other kernel hackers as well. When there is a developer who is responding to the feedback along with a working driver, getting it into the mainline kernel—where more eyes can scrutinize it—is seen as a positive step. Torvalds is very interested in seeing drivers earlier so that more collaboration can happen:

I'd really rather have the driver merged, and then *other* people can send patches!

The thing is, that's what merging really means - people can work on it sanely together. Before it's merged, it's a lot harder for people to work on it unless they are really serious about that driver, so before merging, the janitorial kind of things seldom happen.

Other maintainers explained their criteria for accepting drivers that are not quite up to usual kernel standards. The consensus seems to be that drivers with the following characteristics are acceptable:

compiles and seems to work
has no obvious security holes
has an active maintainer
does not affect people who don't have the hardware
does not introduce unnecessary or not fully thought out user space interfaces

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.

(Log in to post comments)

here, here!

Posted Feb 28, 2008 16:17 UTC (Thu) by sbishop (guest, #33061) [Link]

I worked as an assistant/tutor in my university's computer science lab.  We had two professors
who taught the introductory courses, one who enforced a coding style and one who didn't.  The
other assistants and I often commented on how much easier it was to help the students in the
class where a consistent style was enforced.

hear, hear!

Posted Feb 28, 2008 16:52 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

The expression is "Hear, hear!", meaning "everybody listen to what this guy said".

Consistent coding style

Posted Feb 29, 2008 19:37 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

We had two professors who taught the introductory courses, one who enforced a coding style and one who didn't. The other assistants and I often commented on how much easier it was to help the students in the class where a consistent style was enforced.

Was it because the style was consistent or because the professor picked a good style?

I spent the early part of my software engineering career at a large company that had company-wide coding standards. I was taught, and believed, that it is easier for someone to read code where the indentations are where one expects them, the variable names in the case one is used to, etc. Later, I started working with open source code written by the public at large and found that it's actually trivial to adjust to someone else's style, as long as we're just talking about arbitrary style differences.

Adjusting to a bad style, such as using global variables or 500 line subroutines, is obviously another matter.

Consistent coding style

Posted Mar 3, 2008 3:48 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]

I'm sure part of it is due to picking a reasonable style.  Inexperienced programmers don't
necessarily know what "reasonable" is yet.  I wouldn't doubt, though, that a good part of it
comes from the benefits of consistency across a code base.

Part of the reason it's often easy to adjust to a given FOSS project's style is that it's very
likely to be reasonable and consistent across the source base.  Once you get accustomed to the
particular style/flavor, it's easy to see through it to the code.  The fact that each source
file has the same style helps.  Sure you have to switch gears when you come to the project,
but you're not doing it file to file.  You're doing it project to project, which is a pretty
coarse grain.

In the context of grading coursework, I see both aspects playing a role.  You've gotten the
students off on the right path by giving them a (hopefully) reasonable style.  Also, since
each assignment should be using the same style, you aren't having to switch gears with every
source file.  When you are grading 100 assignments, I'm sure that makes a lot of difference.