Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Linux Kernel Has Grown By 225,000 Lines of Code This Year, With Contributions From About 3,300 Developers (phoronix.com)

Posted by msmash on from the where-we-are dept.

Here's an analysis of the Linux kernel repository that attempts to find some fresh numbers on the current kernel development trends. He writes: The kernel repository is at 782,487 commits in total from around 19.009 different authors. The repository is made up of 61,725 files and from there around 25,584,633 lines -- keep in mind there is also documentation, Kconfig build files, various helpers/utilities, etc. So far this year there has been 49,647 commits that added 2,229,836 lines of code while dropping 2,004,759 lines of code. Or a net gain of just 225,077 lines. Keep in mind there was the removal of some old CPU architectures and other code removed in kernels this year so while a lot of new functionality was added, thanks to some cleaning, the kernel didn't bloat up as much as one might have otherwise expected. In 2017 there were 80,603 commits with 3,911,061 additions and 1,385,507 deletions. Given just over one quarter to go, on a commit and line count 2018 might come in lower than the two previous years.

Linus Torvalds remains the most frequent committer at just over 3% while the other top contributions to the kernel this year are the usual suspects: David S. Miller, Arnd Bergmann, Colin Ian King, Chris Wilson, and Christoph Hellwig. So far in 2018 there were commits from 3,320 different email addresses. This is actually significantly lower than in previous years.

9 of 88 comments (clear)

  1. Lines of code by SCVonSteroids · · Score: 2

    Why do we measure in lines of code? Serious question.

    --
    I tend to rant.
    1. Re:Lines of code by ShanghaiBill · · Score: 4, Insightful

      Why do we measure in lines of code? Serious question.

      LOC is an important metric, for quantifying both progress and complexity.

      The mistake is assuming that more is better.

    2. Re:Lines of code by fahrbot-bot · · Score: 3, Insightful

      Why do we measure in lines of code? Serious question.

      LOC is an important metric, for quantifying both progress and complexity.

      And yet, LOC doesn't necessarily quantify either progress or complexity.

      --
      It must have been something you assimilated. . . .
    3. Re: Lines of code by jd · · Score: 4, Informative

      Lines of code tells you how much work was put in.

      The ratio of lines of code to code blocks tells you how maintainable the code is.

      Defect density tells you the quality of the code.

      A triple of these would give you a reasonable analysis.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  2. LOC != kernel bloat by Zero__Kelvin · · Score: 4, Informative

    An important caveat here is that increase in LOC count does not mean a linear increase in loaded kernel memory usage. For example, for every new driver each line of code is counted, but that driver may or may not compiled in or loaded as a module. If a driver for wireless card X is 1200 lines of code, but your system doesn't have that card and it was compiled as a module, then zero of those added lines of code generated machine code get loaded at runtime .

    There are more than 1000 .config options, and over 30 supported hardware architectures, so your code mileage *will* vary.

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  3. How many bugs in, say, 10,000 lines of code? by QuietLagoon · · Score: 3, Interesting

    What's the rate of bug occurrence per 10k LoC in the Linux kernel? I'm less concerned about additional kernel bloat than I am about additional kernel bugs.

    1. Re:How many bugs in, say, 10,000 lines of code? by Anonymous Coward · · Score: 3, Informative

      For example, this: https://scan.coverity.com/proj...

      They state 0.45 defects/kLOC. Of course, they won't "find" all defects... and there might be some false positives in there. But you get the ballpark.

      Use your favourite search engine (hopefully not Google and its ilk).

      Kids, these days. When I was young, I queried Altavista with telnet. Tsk, tsk.

  4. Kernel code or drivers? by Gravis+Zero · · Score: 2

    What really matters here is if we are talking about if this is a lot of code that has a direct effect on the functionality of all kernels or if this is really about code for specific kernel drivers. Last I read, the kernel core was like 2M LOC while kernel drivers made up 31M LOC.

    --
    Anons need not reply. Questions end with a question mark.
  5. Uncontrolable Bloat by aberglas · · Score: 2

    If those statistics are really true. Over 200,000 NEW lines in one year in an existing, complex system is as unmanageable as 3000 contributers. As products age, the rate of additions goes down as things have to be integrated into a complex system.

    Sure, Linux is not actually as monolithic as described. But a bug in any one of those lines could bring down the whole kernel.

    It is a credit to skill of the maintainers that they can make this work. And a debit that they try.