| concentrating on correctness for kbuild 2.5. MEC mantra:
|
| Correctness comes first.
| Then maintainability.
| Then speed.
Sounds wrong to me... maintainability is done best at design time,
with modularity and by making things table driven where it makes sense.
Unless you hack at it until it works, then start with a new design to
implement what you learned, maintainability is better "built in not
added on" as the commercial says. Correctness is both a design and
implementation issue, of course.
If you design to be maintainable then correctness and speed are easier
to achieve because changes are easier and have fewer side effects.
As an example, the recent VM wars center on trying to see what works
badly and fixing it, rather than being a complete rewrite from scratch
of what has been learned and how to apply it. If the original design
had been made for easy changes, say by putting all the code in a
module, you could have a range of VM modules and a single source tree,
with options selected at boot time, perhaps.
I sense that there are many thoughts on dispatching as well, another
place where theories could be put into modules. Perhaps in 2.5?
-- bill davidsen <davidsen@tmr.com> "If I were a diplomat, in the best case I'd go hungry. In the worst case, people would die." -- Robert Lipe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/