| |||||||||||||
Time to slow down?Time to slow down?Posted May 8, 2008 4:24 UTC (Thu) by jordip (guest, #47356)Parent article: Time to slow down?
Basically we reached or are about to reach 10.000.000 lines of highly critical C code. Metrics are difficult, bugs appears, the world in chaos. If the thing is still going on at a fast speed and with relatively few bugs is by a brute force method of having tons of eyes and hands on the code. Clearly, even with kernel's increasently good management and new tactics to aliviate it, it is not a good prospect, in some years we will have twice the code size, etc. I don't know what would be a nice solution to this situation, maybe limiting the functions drivers can use. And kernel assuming drivers can fail. So driver's code can not work but will not make the kernel crash (drivers is most of the code)
(Log in to post comments)
Time to slow down? Posted May 8, 2008 19:58 UTC (Thu) by jbailey (subscriber, #16890) [Link] I'm curious what the stats are of code with the drivers removed. Code growth through drivers and archs that 95% people of people won't run in their kernel isn't that interesting. I have a vague feeling (without proof) that the core kernel sans drivers is not growing that dramatically. Subsystems already have their own maintainers and review systems. Scaling then happens with the splitting into subsystems and driver maintainers, etc. So not actually a problem in the longer term, even though total LoC churn would be very high.
Time to slow down? Posted May 9, 2008 18:16 UTC (Fri) by gregkh (subscriber, #8) [Link] The kernel code is growing in an exact proportion to the amount it contains within the kernel itself. So, for example, the core kernel makes up 5% of the overall size. And exactly 5% of the changes happen in the core kernel code itself. Same goes for every other category of the kernel code, it's pretty amazing. I have a script that digs all of these numbers out of the changelogs on my kernel.org directory for these kinds of statistics.
|
|||||||||||||