Is Linux bloated? Hardly

10/12/2009 1:53 PM EDT

Various sources place the size of the current Linux kernel source tree at more than 11 million lines of code [1]. Other impressive statistics include over 5000 individual developers to date, including the more than 1000 that worked on the current kernel release alone. More than 12,000 lines of code relating to more than a thousand individual changes, enhancements or bug fixes are added, deleted, or changed in each kernel release [2]. Linux has more than doubled in size since 2005, and at its current pace will double in size again well before 2013.

But as impressive as they are, do the above statistics equate to "bloat?" In a word, No.

One source of Linux's perceived heft is its support for a bewildering array of peripheral devices. There are more than 85 different types of devices represented, and each type provides a home to at least half a dozen—and in some cases more than a hundred—actual device drivers. In the most recent kernel release, the source code for the drivers/ directory outweighs the code in the kernel/ directory (which holds the code for the kernel proper) by a factor of 23. If one penguin weighs ten pounds, and another weighs 230 pounds, which one is fat?

Linux's driver support is absolutely necessary, however, so you can hardly call that a source of "fat." The diversity of platforms that run Linux demands an equal diversity of device support, and the only way to keep those device drivers up-to-date with the latest kernel APIs is to make sure they can be automatically and routinely tested. And the best way to do that is to bundle them with the kernel source code itself.

Fortunately, the Linux KConfig build system allows you to turn off support for all but the devices you absolutely need. Hence, the total size of the driver source code in a kernel release is in no way correlated to the size of a kernel that has been properly configured for a specific target.

Device driver diversity isn't the only place where Linux appears to look overweight, but really isn't. The current kernel release supports 22 different instruction set architectures, by far the largest of any popular operating system kernel ever created. But Linux supports only one architecture at a time, so at least 95% of the code in the arch/ subdirectory of the kernel source tree never makes it into a final kernel build. I use the term "at least" deliberately here, because even a kernel configured for an ARM target can't support all ARM chips, so only a fraction of the code under arch/arm/ ever finds its way into a platform.

Finally, consider the fact that the overall performance of the Linux kernel itself has gotten measurably better with each kernel release. I routinely benchmark on a fairly ordinary ARM platform, and have seen the kernel's scheduling precision and interrupt latency improve by a factor of 100 over the last ten kernel releases. The kernel's overall throughput has improved as well, yet its memory footprint has not grown significantly over the same period. So where's the fat? Someone will have to point it out to me, because I just can't see it.

I don't have a problem with Linus saying that Linux is huge and scary. But bloated? No. The only thing I can find in limitless quantities is opportunity to use the Linux kernel to solve new and interesting problems. And that's the kind of fat I can really sink my teeth into. The rest of this penguin is lean and mean.

References
1. "Linux is Bloated, Just Not How You Think." Linux Magazine, September 23, 2009.
2. "Linux Kernel Development: How Fast is it Going, Who is Doing it, What They are Doing, and Who is Sponsoring it." August, 2009, The Linux Foundation.

About the author
Bill Gatliff makes Free and Open Source technology work for embedded systems. Specializing in Linux kernel porting and real-time applications for more than a decade, Bill also provides some of the most sought-after, in-depth, up-to-date consulting and training on topics related to real-world embedded platforms and applications. His background includes automotive, industrial, aerospace, and medical devices. Bill is a contributing editor to Embedded Systems Design Magazine, and a member of the Advisory Board to the Embedded Systems Conference. He can be reached at bgat@billgatliff.com.