mainboard sub-type support

[Jeremy Jackson]

It would also be best to avoid copying whole files.  It's the whole
pass-by-value vs pass-by-reference argument.  Copy whole file is a
nightmare for maintenance, while #including stuff like cmos layout could
break a system being upgraded.

Shouldn't p4dpe/Config and p4dpr/Config contain only the parts that
differ? ie:

[jjackson at thunderdome supermicro]$ diff p4dpe/Config p4dpr/Config
58c58
< mainboardinit mainboard/supermicro/p4dpe/pci_clk_reset.inc
---
> mainboardinit mainboard/supermicro/p4dpr/pci_clk_reset.inc
66c66
< mainboardinit mainboard/supermicro/p4dpe/select_i2c_spd.inc
---
> mainboardinit mainboard/supermicro/p4dpr/select_i2c_spd.inc
74c74
< mainboardinit mainboard/supermicro/p4dpe/mainboard_raminit.inc
---
> mainboardinit mainboard/supermicro/p4dpr/mainboard_raminit.inc
94c94
< #object devices.o
---
> object devices.o
225c225
< option MAINBOARD_PART_NUMBER=P4DP6
---
> option MAINBOARD_PART_NUMBER=P4DPR

And then #include at start or end p4d/Config_common or some such.

Is there an #include like statement for Config files?  You could always
make one, or does the order of the entries count here?  I've seen OOP
guys go nuts about proper code factoring, and aside from being seen as
fascist, they have really clean code.


On Tue, 2003-02-04 at 11:51, Ronald G. Minnich wrote:
> On 4 Feb 2003, Jeremy Jackson wrote:
> 
> > Will the shared code/common files still be in p4d/, and be referenced or
> > included by the config/other files in p4d/{pe,pe-g2}?  If so it makes
> > perfect sense.
> 
> yes, and it works really well. 
> 
> I'm going to flash the image I created from this scheme and let you know. 
> 
> For the moment I'll leave it at the p4dpe and p4dep/g2 variant, I want to 
> see if I get any other comments. 
> 
> Thanks Jeremy!
> 
> ron
-- 
Jeremy Jackson <jerj at coplanar.net>