Messages in this thread |  | | Date | Tue, 22 Aug 2000 23:05:44 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you |
| |
On Tue, 22 Aug 2000, Eric S. Raymond wrote:
> Sharing code is a way to increase the test population for the shared > parts, which increases expected test coverage on the shared parts, > which is good. It's especially good because the shared parts tend to > have subtler bug signatures than the unshared parts (data structure > corruption is harder to diagnose than a device lockup), so the better > test coverage happens exactly where it's most needed.
this argument is flawed because it assumes a constant (static) 'requirements space'. But in RL (such as Linux) requirements change dynamically, new CPUs, new hardware (new users :-) arrive at an ever increasing rate.
for a static requirements space what you say is 100% correct. Sharing must be maximized to get maximum test coverage - end of story. But in an OS that tries to be practical in an ever changing world governed by the laws of physics, it's more important to reduce algorithmical complexity, to speed up debugging and other time-constained activity that does not happen in an 'ideal world'. Part of the requirements are that we should both support new hardware, new hardware features, and should stay stable on old hardware, and we should be the fastest on the planet.
as you might notice if you check out the kernel code, there are parts that are less affected by external forces (a process is a process is a process), there we have very good code sharing. But in subsystems where requirements are more dynamic, we tend to create 'snapshots' of code, let the old code around and thus free the new code of the burden of having to support old stuff - instead of trying to support everything at once.
this is analogous to what happens in the real world as well - water over time flows to the lowest spot and becomes a lake - still we have 'seemingly impossible' things like rivers and waterfalls, which do not make sense in a static-only environment.
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |