KS2010: Big out-of-tree projects
Roland started off by talking about the OpenFabrics Enterprise Distribution (OFED), which is described as:
In reality, it's a large chunk of out-of-tree code distributed by the OpenFabrics alliance. There are a number of enhancements to the InfiniBand infrastructure, backports to older kernels, and so on. Hardware companies have been telling their customers to use the OFED stack instead of mainline; the enterprise distributions have been shipping it.
So why does OFED exist? Roland says it's partly his fault; he has not been merging stuff into the mainline quickly enough. He has had trouble getting people to help review all of that code. But, he says, there is also an incentive for OFED: it gives the OpenFabrics Alliance an ongoing reason to exist. Perhaps OFED should go into the staging tree? The OFED tree consists mainly of patches to code which is already in the mainline; it's not a set of standalone drivers which can sensibly be put into the staging tree.
It was suggested (nobody was able to confirm it) that Red Hat will not be shipping updated OFED stacks in the future. Chris said that the distributors need to push back more against this kind of out-of-tree code. Oracle, he noted, is doing that.
Ted Ts'o asked about the scope of the problem - what other large, out-of-tree projects exist? The list started with Xen's Dom0 code. Jeremy Fitzhardinge took a moment to update the crowd on the status of Dom0; most of the trickiest bits have been merged for 2.6.37, so it's actually possible to boot a Dom0 kernel. There are no backend drivers, though, so that kernel will have no devices available; Jeremy allowed that this limitation reduces the usefulness of that kernel somewhat. Some of those drivers will be merged in forthcoming development cycles; others are so ugly that they may never get in.
Other significant out-of-tree projects include the Lustre filesystem, the realtime preemption tree, OpenVZ, the LTTng trace kit, the grsecurity patches, and the always controversial SCSI target code. In general, it was agreed, we are doing much better than before.
The process needs to continue, though. According to Chris, Oracle has found every vendor driver it has ever encountered to be horribly broken and unsupportable. So Oracle has taken a strong position that only upstream drivers can be supported. Ted said that, for enterprise systems, the problem has mostly been solved; the same is, alas, not true in the embedded area. So we will have to go through the same education process with embedded vendors.
It may be the same problem, but out-of-tree code may be harder to eradicate in the embedded world. Vendors of embedded systems are incredibly price-sensitive; upstream drivers fall by the wayside when compared to a savings of a few cents on a component. What's needed is to make "upstream drivers" a stronger part of the procurement process; it must be a technical requirement for any candidate components. Tim Bird said that this problem had been discussed at a recently concluded embedded Linux summit; the result is a new effort to encourage a "preference" for open-source drivers. Many vendors apparently claim that they have never even heard that free drivers are preferable; the first step is to cure them of that impression.
The session concluded with a statement that, while out-of-tree projects still exist, things have improved and are continuing to do so.
| Index entries for this article | |
|---|---|
| Kernel | Development model |