On Thu, Sep 27, 2007 at 10:21:56PM +0200, Robert Millan wrote:
I strongly disagree with this approach. Duplicated code is bad, bad, bad and should be avoided whereever possible.
If we look at it in perspective, I think the cons for each option can be summarised as:
- duplicate: someone might waste time debugging/implementing/fixing something that was already done at the other branch.
- include: someone might break board A in a commit that was only tested on board B.
AFAICS, the second is no big deal, it just takes a regression test which is something even I can do ;-)
Yep. Just look at some other hardware-related projects, e.g. the Linux kernel. Nobody cut-n-pastes a new driver for every ethernet card in existence, for every sound card, every USB mouse etc. There's a common framework, the specific drivers (mostly) only contain the code which is _specific_ to the respective hardware.
That not only reduces the code complexity and the likelyness for bugs, and makes it easier for other developers to understand the code. It also makes sure that all parts using the framework benefit from bugfixes (vs. fixing one sound card code-base and the rest of the 800 cards still contain the same bug, for example).
Really, this is my #1 priority for LinuxBIOS (v3, but also v2) -- reduce code duplication as much as we can. Look at src/superio/smsc/smscsuperio (which handles 15 Super I/Os or so) and try to imagine how that would look like if we had copy-pasted each of them from some other codebase and just tweaked it here and there. We'd have 15 directories full of crap.
Common "framework" code which handles whole _families_ of hardware parts (be it mainboards or superios or chipsets, whatever) should definately be our long-term goal.