Hi folks,
<big_snip>
Just a few naive thoughts:
a) What about reducing code size ?
Some parts, IMHO, doen't necessarily need to be in the kernel,
eg. certain filesystems. Less code, less patches to review, less
chance of kernel bugs. Of course this might also cause other
impacts (eg. performance), so those decisions require great care.
b) Mutli-tier trees / patchlines
IMHO, a major problem are conflicting patches (eg. a core change
causes some driver to break). In measurement instrumentation
(eg. timesync), there's typically one primary reference point
(eg. atomic clock) as tier-0, where (a limited set of) tier-1's
are synchronized against, tier-2 syncs against tier-1 and so on.
So for the linux kernel, we perhaps could have something like:
* tier-0: core
* tier-1: arch
* tier-2: hw drivers
* tier-3: sw drivers
* tier-4: userland interfaces
If a change from a lower tier wants to it's upper tier, it first
MUST fit it's current mainline and carefully checked. Of course
this introduces longer times for an individual change to go to
into release (since it has to pass several tiers), but IMHO the
chance of new bugs in release should be reduced this way.
Of course there might be chances in a lower tier, which obviously
won't affect several intermediate tiers. Those could skip some tiers.
For example, I'm currently working on an /proc interface for
changing process privileges. In my model, this had to be settled
in #4, but shouldn't touch drivers (#2,#3), but maybe arch (#1).
So these changes could be kicked directly to #2.
What do you think about this ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
