“Mike started the talk by giving the developers a good laugh: it
seems that Google manages its kernel code with Perforce. He
apologized for that. There is a single tree that all developers
commit to. About every 17 months, Google rebases its work to a
current mainline release; what follows is a long struggle to make
everything work again. Once that’s done, internal “feature”
releases happen about every six months.“This way of doing things is far from ideal; it means that
Google lags far behind the mainline and has a hard time talking
with the kernel development community about its problems.“There are about 30 engineers working on Google’s kernel.
Currently they tend to check their changes into the tree, then
forget about them for the next 18 months. This leads to some real
maintenance issues; developers often have little idea of what’s
actually in Google’s tree until it breaks.“And there’s a lot in that tree. Google started with the 2.4.18
kernel – but they patched over 2000 files, inserting 492,000 lines
of code. Among other things, they backported 64-bit support into
that kernel. Eventually they moved to 2.6.11, primarily because
they needed SATA support. A 2.6.18-based kernel followed, and they
are now working on preparing a 2.6.26-based kernel for deployment
in the near future. They are currently carrying 1208 patches to
2.6.26, inserting almost 300,000 lines of code. Roughly 25% of
those patches, Mike estimates, are backports of newer
features.”
KS2009: How Google uses Linux
By
Jonathan Corbet
Get the Free Newsletter!
Subscribe to Developer Insider for top news, trends, & analysis