On Thu, Sep 27, 2007 at 10:21:56PM +0200, Robert Millan wrote:
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
- 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.