mainboard sub-type support

[Ronald G. Minnich]

We have a mainboard called the p4dpe-g2. It seems to be almost identical 
to the p4dpe.

I was faced with several options: 
- have a directory named p4dpe and a directory p4dpe-g2, with
  almost identical files

- Have a directory for the p4dpe, with #ifdef G2 in many files

- an interesting trick that works: 
  have a directory p4dpe, and a directory p4dpe/g2
  Populate p4dpe/g2 with the files: 
    cmos.layout, Config, mainboard.c, irq_tables.c, and mptable.c
    in other words, the files that will change with mainboard revs
    anyway

This last option works. The only change to the config file to build a -g2
motherboard is to change the line:
mainboard supermicro/p4dpe
to
mainboard supermicro/p4dpe/g2

Now this is kind of interesting. For a vendor like supermicro that spins 
lots of boards that are very similar, we can take this further: have
supermicro/mainboard/p4d/pr
for the p4dpr
and 
supermicro/mainboard/p4d/pe
for the p4dpe. These are similar boards, lots of shared code, and this 
structure shows that.

Comments? is this good, bad, or indifferent?

ron

[Jeremy Jackson]

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.
There could also be a mailboard/common/ dir for files (if any) common
across more than one mfr's mainboard.

On Mon, 2003-02-03 at 19:27, Ronald G. Minnich wrote:
> We have a mainboard called the p4dpe-g2. It seems to be almost identical 
> to the p4dpe.
>
> I was faced with several options:
>
> have a directory named p4dpe and a directory p4dpe-g2, with
> almost identical files
>
> Have a directory for the p4dpe, with #ifdef G2 in many files
>
> an interesting trick that works: 
> have a directory p4dpe, and a directory p4dpe/g2
> Populate p4dpe/g2 with the files: 
>  cmos.layout, Config, mainboard.c, irq_tables.c, and mptable.c
>  in other words, the files that will change with mainboard revs
>  anyway
>
> This last option works. The only change to the config file to build a -g2
> motherboard is to change the line:
> mainboard supermicro/p4dpe
> to
> mainboard supermicro/p4dpe/g2
>
> Now this is kind of interesting. For a vendor like supermicro that spins 
> lots of boards that are very similar, we can take this further: have
> supermicro/mainboard/p4d/pr
> for the p4dpr
> and 
> supermicro/mainboard/p4d/pe
> for the p4dpe. These are similar boards, lots of shared code, and this 
> structure shows that.
>
> Comments? is this good, bad, or indifferent?
>
> ron
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[Ronald G. Minnich]

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]

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@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

[Ronald G. Minnich]

On 4 Feb 2003, Jeremy Jackson wrote:
> 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.

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

remember, including is the basis of the config tool. So yes you can do 
something like this. I'm still working out all the details.

ron