LWN: 内核staging目录的驱动们最后下场如何？

点击上方蓝色“Linux News搬运工”关注我们~

What happens to kernel staging-tree code

By Jonathan Corbet

staging tree是2008年在2.6.28版本开发周期中加到kernel里的，目的是希望能帮助那些尚未标准化的驱动程序逐步完善并合入mainline( kernel主线)。这么多年来它一直存在争议。最新的关于EROFS和exFAT文件系统的争论，再一次引起大家讨论这个staging tree具体是不是真的对kernel社区有价值。LWN也无法回答这个问题，不过我们可以分析一下过去11年里加入staging tree的东西来看看是否能有一些结论。

staging tree的主要特点是它对加入的代码持有更开放的态度，不用参照通常合入kernel代码时所需要的严格标准。如果某个驱动程序加入staging tree了，任何人只要胆子够大就可以直接试用。不过它其实更深层次的目标是让开发者能继续改进代码从而最终以更正式的方式合入kernel合适的位置。新加入的开发者可以在这里试一些简单的改动，如果效果不错，Linux就能得以支持这种新的硬件设备。没有staging tree的话，这些试验性的东西可能就永远无法合入kernel了。

有些人并不赞同这种工作方式（先把代码放进kernel再改善）。以exFAT为例，其实很多开发者都认为如果把它合入staging tree的话，它自己改善的速度可能还不如拒绝合入。正如Dave Chinner所说：“这类改动在mailing list上会更容易完善以及进行review。并不需要把这个代码合入staging tree。其实如果真把它先合入了，那么后续很难进行架构改动，因为它只能慢慢的随着kernel开发周期来慢慢迭代。”

Greg Kroah-Hartman是staging tree的maintainer（维护者），他的回复指出合入代码能够给各位开发者一个很好的平台来进行合作。他也承认可能会让开发进程变慢一些，不过他认为这个代价很值得，尤其适合有很多人需要配合来改进这部分代码的情况。

LWN编辑发现其实没有人真正审查过去11年曾经进入过staging tree的这些模块。于是我简单写了脚本以及对Git进行各种查找，拿到了不少数据，展示了每个模块进入staging tree还有从中删除的时间。然后进行大量的人工分析，来调查每个模块离开staging tree的原因。现在终于昨晚了，结果如下。

Graduations (特指从staging tree毕业进入正常kernel代码库)

统计中有247个模块进入了staging tree。其中有52个“毕业”了，占总数的21%，包括：

(注：releases列包括了把这个模块从staging tree中拿掉的那个release版本，因为这个动作属于那次release cycle)。

有些模块比其他的更快的毕业了。例如altera-stapl驱动，经过3此发布周期就毕业了。相对应的，industrial I/O light模块则经过了46个发布周期，将近9年的时间。不管它们都经历了多长时间吧，每个模块都在不断改善之后得到了相应子系统维护者的接受。

这里成功率才21%，看起来并不高。不过这种看法并不全面。大量staging tree中的驱动程序最终都被删掉了，因为mainline里面有其他的驱动程序实现了它的功能。这类被替代的模块是：

所以有37个驱动程序有替代模块合入了mainline，占比15%，当然它们每个都有不同的情况，各有成败。有些staging的驱动太难看了，所以激发了其他开发者的完美主义情结，从头写了一个更好的驱动提交上去，这种情况下我们可以认为这个staging驱动也是成功的，毕竟达成了它的目标。另外一种情况下是相应的硬件供应商提供了官方驱动，例如很多Realtek驱动都是这么来的。还有一类情况是staging驱动提供了很多信息，帮助其他人写出了更好的驱动，这也是有价值的。

上述的驱动程序最终都在某种意义上进入了mainline。虽然很难估计把各个驱动放到staging tree究竟有多大帮助，不过最终能支持这类硬件，应该就是社区的成功了。

Failures

还有很多驱动最终就从staging tree里删除了，相应的功能也就不再存在了。

这里有60个模块，占比24%。绝大多数最后一个commit都是说“很久没人继续开发这个模块了，该放弃了”。其中有的是支持了从未量产的硬件，或者是某些太古老没人用了的硬件导致没法继续开发。有些情况，例如LTTng tracing模块，这个代码基本上马上就被拿掉了，因为开发者不赞成放入staging tree。还有至少一例是因为license问题拿掉的。

无论如何，上述每个模块都代表了一段没能最终孵化出成果的工作。staging tree不可能把100%的模块都最终放入mainline，至于这24%的失败率算不算高，大家就见仁见智吧。

Staging out

2008年设立staging tree的时候，起始并没有想到它还会成为某些开发者希望拿掉的代码的最终栖息地。现在，如果看起来没人在用的驱动程序，就会被放到staging tree里，过几个版本之后，如果没有人抱怨，就会彻底删除。如下驱动都是这样离开kernel代码的：

这27个模块，占比11%，都是来自kernel正式代码并最终惨遭删除的。删除不再需要的代码，肯定是件好事啊，所以这应该算是staging tree做的好事情。不过可惜只有很少数模块是这么stage out的。kernel里还有众多驱动其实也没有在用了，仍然保留在原位。

Hangers-on

最后一类，就是目前在5.3-rc7 kernel里面仍然保留在staging tree的模块了：

所以在总共247个进入staging的 模块中，有71个仍然存在，占比29%。其中呆了最长时间的是comedi子系统，自从2008年11月加入之后，关于staging tree的全部53512个commit中有8673个都是关于comedi的，占了driver/staging目录下改动commit的16%。还有其他一些模块也在staging tree存在了很长时间，不知道staging tree是不是有年数限制，反正看起来不像是有。

其中有一些应该已经快要毕业了。Kroah-Hartman指出comedi, greybus, speakup都只要再做一点工作就可以毕业了。Greybus驱动应该会合入5.4。其他不少代码其实应该需要删掉的，Greg也说他其实已经有几年没有去清理一遍了。也会有不少代码会继续存在不少时间。

Exit stage right

所以目前的结论是：

虽然没法回答起初的问题“staging tree是否对kernel开发有益处”，毕竟大家都理解通常一件事物都是对某些模块有好处却对其他模块没有好处。不过可以看出的是确实有不少代码都经过staging tree进入了正式kernel，整体上来说也帮助mainline kernel变得更加整洁。无论大家喜欢staging tree与否，它都是kernel开发流程中的一部分了。虽然随着大家对它的评价和压力变化，它的角色会不断改变，不过今后很长时间里面它应该都是kernel开发的一个重要部分。