[LinuxBIOS] [PATCH] Common code base for Advantech PCM-5820, ASI MB_5BLMP, BCOM WinNET100

Uwe Hermann uwe at hermann-uwe.de
Wed Oct 24 00:08:58 CEST 2007


On Tue, Oct 23, 2007 at 04:39:00PM +0200, Peter Stuge wrote:
> > The #elif's are a cheap price when we can get rid of all the
> > duplicated files we had before.
> 
> For v2, I think I'm with Ron. Duplicated code and files isn't that
> bad. Yes, it's dirty, but rather than cleaning it up piece by piece
> I'd like to work on v3.

Sure, but working on v3 doesn't mean we necessarily have to let v2 bitrot.

I think it's pretty clear that I totally dislike duplicated code (_the_
single biggest problem of the v2 codebase if you ask me), but I
understand that it may not be _that_ dramatic with the GX1 or 440BX
boards (which are -- or can be made -- very small and clean anyway).

The bigger problem is more recent boards. Look at m57sli, a8n_e, etc.
Those not only contain board-specific config items (which would be
ideal), but rather board-specific _code_ (which is not nice and we should
avoid that in v3), and worse they contain (contrary to GX1/440BX)
a _lot_ of duplicated or near-duplicated code.

Maybe we don't even have to fully merge the boards in v2, some simple
cleanups in the current code base would also be helpful, I think.

Config.lb:

 - Can easily be made totally generic to work for _every_ board we use.
   The only really specific part in there is the static device tree,
   all the other blurb could as well be in a common file.

   Hm, do Config.lb/Option.lb files support an #include-like mechanisms?

Options.lb:

 - Not needed at all, IMHO. We could just drop them all, I think.
   95% of those files is the same for each board, the rest can be
   easily set to some sane default and overridden in
   targets/.../Config.lb as needed.

Other files, such as get_bus_conf.c, irq_tables.c, mptable.c,
resourcemap.c etc. are twistly little mazes. They partly hardcode
information such as the number of certain devices in C code etc.
This is where it gets really ugly. I'm not sure I can be bothered to
create patches to fix _that_ in v2, but I'd really appreciate it if
v3 would have that kind of information as a simple config value part
of the dts.


> > There are just 2-3 places where you have to add your board in the
> > #elif.
> > 
> > On the long run (in v3 maybe)
> 
> How long is "long" ?

No idea. As short as possible, of course, but just like anyone else
I have no release date.


> I would much rather see this effort go into v3 and a bonus is that

Sure, I'm willing to also provide patches to eliminate any uselessly
duplicated code from v3.


> many of the boards supported by v2 would be working also with v3.

Can you elaborate? How does eliminating duplicated code help or not help
in supporting v2 boards in v3? Those issues are not really related IMO.


> #ifdef/#elif is really ugly. At least do #include instead?

Could be done, yes. Would such a patch be accepted?


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/20071024/76746dc5/attachment.sig>


More information about the coreboot mailing list