Add to del.icio.us     Digg this

Jul. 19, 2010

Ask almost anybody in the Linux community and they will tell you that a typical development cycle can easily have more than 10,000 changes merged into the Linux kernel at any point in that new development cycle.

Linus Torvalds still plays an active role in the development of the Linux kernel.

The number of security and other 'patches' going directly into the mainstream has dropped significantly, however. Almost everything goes through somebody else's desk first. What's left for Linus, at this point, is mostly release tagging, urgent fixes and reverts.

Additionally, Andrew Morton remains the maintainer of last resort for much of the Linux kernel today, but increasingly, changes are not going through him all the time. The number of changes is staying roughly the same from one change to the next, however.

There isn't really any need for more changes despite the increase in the number of kernel subsystems over time. We're also approaching the natural limit of how many subsystem change requests one talented contributor can pay attention to.

It stands to reason that the number of kernel change requests handled by Linus Torvalds cannot increase that much either. If the Linux community continues to grow as it is, there could eventually be a scalability bottleneck somewhere. The only real question is where it might be.

Another solution would be to empower others to push the development cycle into the mainstream. It's not clear that anybody is ready for such a radical change in the development process, though.

Ted Ts'o's 1998 warning to anybody wanting a core team model still bears reading nearly twelve years later. But if Linus is to retain his central position in the kernel's overall development, the Linux community as a whole needs to ensure that the process scales.

Maybe what is called for would be a new ARM architecture tree again, and perhaps there could be a place for a tree which would collect most driver patches, but not everybody agrees with this.

One approach would be to change the fact that almost all trees are pulled directly into the mainstream. Subsystem maintainers who have earned sufficient trust could possibly handle more lower-level change requests and present a result to Linus that he can merge with relatively little worry.

The networking subsystem already works that way. A number of trees feed into David Miller's networking tree before being sent upward. Meanwhile, other pressures have led to the opposite thing happening with the ARM architecture: there are now several subarchitecture trees which go straight to Linus as a result of that.

The overall number of ARM changes seems to have been a clear motivation for Linus Torvalds to shut things down during the 2.6.35 merge window, however.

Overall, the Linux kernel and all its many development cycles have a much higher profile today than they did in 2001 and 2002.

If the process were to slow again again due to scalability problems, the resulting confusion would be played out in a public way. While there's still no danger of immediate trouble lurking anytime soon, we should not let the smoothness of the process over the last several years fool us into thinking that it cannot happen again.

As with the Linux code itself, it makes sense to think about the next level of scalability issues in the kernel development process before they might happen again.

Add to del.icio.us     Digg this

Source: LNB.

All logos, trade marks or service marks on this website are the property of their respective companies or owners.

ADVERTISERS:
Linux News Today.org is read by over 450,000 people involved in the field of Linux application development, professional Web hosting services, Linux security, Linux Web development, etc. Inquire about our reasonable advertising rates on our news website. One of our advertising representatives will be in touch with you. Simply email us to learn about our ad rates and how we can help drive relevant traffic to your website. Advertising space is limited.