mingo@elte.hu (Ingo Molnar) wrote on 23.08.00 in <Pine.LNX.4.10.10008222253380.9502-100000@elte.hu>:
> 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.
That's one aspect.
Another is finding out *how* to do that sharing right.
When your code is riddled with #ifdefs, most people will agree that
something's wrong here.
However, when all those #ifdefs get converted to if()s, something's
*still* wrong here. It's just wrong at runtime instead of wrong at compile
time.
The point here is that when something like that happens, one needs to sit
back and think about abstractions. A new, better abstraction is usually
what is needed in this situation - something that makes most of those
conditionals go away, *stay* away, and possible also take care of a number
of forseeable future ones.
Unfortunately, sometimes the best new abstraction one can come up with is
a driver split. In that case, can we have common subroutines/macros/
definitions at least? Or maybe change macros and leave the rest the same?
Those are also ways to abstract change.
Maybe we can't, or at least we don't know how. Too bad.
Then again, maybe we *can* find ways to handle this without giving up on
common source, and without producing code riddled with conditionals.
*That* is the ideal case.
MfG Kai
-
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