| |||||||||||||
How old is our kernel?How old is our kernel?Posted Feb 17, 2010 17:26 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)Parent article: How old is our kernel?
Wow! I must admit I was rather surprised by the per-subsection numbers. Intuitively, I would have expected more churn in the drivers section (ie. as new drivers get added, old ones removed (ok, that's pretty rare) and wide-spread API refreshes) than in, say, the core kernel.
Quite the opposite is true, though. The core kernel has the lowest percentage, weighing in at 13%! The drivers directory, on the other hand, is way out at about 30%.
The math doesn't work for me, though. How can the whole kernel be at 41% if only one of the subsystems (sound) is noticeably above 41%, Documentation is tied at 41%, and the rest are below? Even fs, net and include (which are near 40%, but below it) should bring the average down. And isn't drivers (which weighs in at ~30%) pretty much where the vast majority of code lives?
Is there some other half-million line dreadnaught hiding that's not captured in the subsystem graph, anchoring the average at 41%?
(Log in to post comments)
How old is our kernel? Posted Feb 17, 2010 19:58 UTC (Wed) by corbet (editor, #1) [Link] Hmm...something may have confused the full-kernel numbers. I'm checking (again) now. I'm quite convinced about the individual subsystem numbers, though. Stay tuned.
Yep, I blew it Posted Feb 17, 2010 20:18 UTC (Wed) by corbet (editor, #1) [Link] The 41% number was wrong; the article has been edited with the correct data.For the curious: the bug was a combination of the tool descending into the .git directory (which has no history of its own) and it attributing unknown lines to the oldest release. That essentially inflated the number of "old" lines in the full kernel by about 2 million - enough to make a big difference. Please accept my apologies for the screwup. I'd taught the program to avoid .git a while back, but I thought it was an efficiency improvement only; I didn't realize it had messed up the full-kernel numbers. Embarrassing.
Yep, I blew it Posted Feb 17, 2010 21:30 UTC (Wed) by jcm (subscriber, #18262) [Link]
Nah, you obviously didn't blow anything - awesomely informative stats, thanks Jon :)
No worries! Posted Feb 17, 2010 22:10 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
No worries! The new number makes much more sense. Since I've seen elsewhere that drivers seem to make up a pretty big portion of the tree, it makes sense that the center of gravity for change-rate would land near there too.
I guess I wasn't too far off (in orders of magnitude) on the number of unaccounted-for lines in the data, although I did undercall it by a factor of 4.
Man, the kernel's gotten huge! I actually tried to download the latest kernel and untar it in a 300MB partition, and it b0rked out, filling the disk only part-way into the "drivers/" directory. Next time I'll do it on a machine with a more generous disk space allotment. :-)
|
|||||||||||||