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/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:08 EST