Kernel space: Merging drivers early

Kernel developers debate the standards for including new driver source code in the kernel. As long as a new driver doesn't break things for people who aren't using the affected hardware, getting it into the kernel in an unfinished state may do more good than harm.

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

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about CVSDMALinuxRolandVIA

Show Comments