Going back to the metrics. I’d say that it shows you how much code is being written and included into the kernel. It surely says about the quantity, because includes and macros are written and placed in one file and reused all over the project. The same goes for code that gets copied and modified only slightly. It still is quantity. I see your point though. Maybe it’d be better to run SLOC on the output of gcc -E (so the macros would be expanded) but seriously if have a mutliline macro like:

#define f_close(f) \
do { \
if ((f) != NULL) \
{ \
fclose((f));\
} \
else \
{\
(f)=NULL;\
printf("f_close: closing closed file?", 0);\
}\
} while (0);


and then when you reuse it just by typing:

f_close(fp);


in reality you’re adding 11 lines or so but you’r effort is this one line.

To recap, these stats are more biased towards effort to write the code.

I know of a project where the usage of macros (the code executed much faster due to inter-statement optimization of the macro code which was deliberately written to enhance this optimization) was effectively penalized, so a very astute programmer had the macros generate source files which up’d a groups source code count to a suitably impressive level.

some feedback:
- now that you mention it, the number of files does look more like 2 linear segments.
- 1 C++ file is reported by CLOC. SLOCCount reports a different structure. I’ll add it to the article:

ansic: 5780304 (96.08%)
asm: 218132 (3.63%)
perl: 6075 (0.10%)
cpp: 3242 (0.05%)
yacc: 2919 (0.05%)
sh: 2609 (0.04%)
lex: 1825 (0.03%)
python: 331 (0.01%)
lisp: 218 (0.00%)
pascal: 116 (0.00%)
awk: 96 (0.00%)

- these stats do include the Documentation directory, eg. 3_bottom.png file.
- it’s true that more lines of code does not mean better quality, I think we should have coverity analysis for that. One thing that these stats hide is the real rewrites. They do happen. Overall stats say about 4300 lines added, 1800 lines removed, 1500 lines modified. See? 1800 lines removed daily!

Thanks for insightfull pointers.

Interesting stats.

It’s not clear to me that things like Kconfig files are included. They are part of the build structure, but are not a standard language. They are critical parts of the make system however.

Also I might quibble with the concept of removing documentation files from the stats. IMHO documentation is as important as the code itself. There has been a few people putting special effort into improving kernel documentation, which leads to increased robustness and ease of adding *more* code.

Anyway, I enjoyed your article. Thanks!

For other plots it is clear the behavior is faster than linear, maybe cuadratic.

SALUDOS
TUXO