> COCOMO says that the cost scales superlinearly with the number of SLoC; my point is that drivers scale linearly because they're effectively separate projects. (In fact, to the extent that they're not separate projects, the cost in fact scales sublinearly since there's a bunch of code being copied and pasted when new drivers are written.) Your tool has this "--multiproject" concept; a better estimate would have identified which parts of the tree (primarily drivers) were functionally separate from the rest of the kernel.

If all drivers were essentially completely independent projects that never interacted with each others, then yes, I'd agree that multiproject would be a better model. And if each was mainly a copy-and-paste of another, then it'd definitely be sublinear.

However, I have a very different expectation. In the Linux kernel, there's a strong pressure to try to create common interfaces that different drivers support. There's also pressure to create common lower-level functions that everyone can call. This reduces total code and reduces long-term maintenance, but ends up creating more interlinkages because the drivers are NOT really isolated separate projects at all. Maybe the drivers start somewhat independent, though I'm skeptical of even that, but I think that's not at all where they stay.

Let's get specific. The Linux kernel groups similar hardware into distinct subsystems. This includes networking, input subsystem (keyboards/mice/etc.), ALSA (sound), V4L2 (webcams/video capture cards), and GPIO.

Each subsystem defines a unified programming interface using standard data structures and callback functions. Drivers are typically split into a core framework that handles general logic and low-level portions. Driver developers plug into the existing framework for common features like power management and buffering. These interfaces often change as new drivers are created that require changes to the interface.

Because in practice there's a lot of interaction among drivers, I would not expect that, after years of driver development, the different drivers would really be independent. Indeed, many have asked the Linux kernel developers to make it easy to have completely separate and isolated drivers, but the developers have resisted because they believe it's important to have the drivers integrated into the kernel to support that kind of constant collaboration between drivers.

It'd be cool to see an analysis to settle the question. Future research for someone else I suppose :-).