[LinuxBIOS] A8N5X port

[Uwe Hermann]

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.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070928/84f958e1/attachment.sig>