[U-Boot] [PATCH v4 2/2] boards.cfg: Delete the equivalent entries

[Albert ARIBAUD]

Hi Masahiro,

On Thu, 13 Feb 2014 15:46:41 +0900, Masahiro Yamada
<yamada.m at jp.panasonic.com> wrote:

> Hello Albert,
> 
> 
> > > 
> > > 
> > > > > There are some entries which produce the same binaries:
> > > > >  - ep8248E           is equivalent to ep8248
> > > > >  - MPC8360ERDK_66    is equivalent to MPC8360ERDK
> > > > >  - Adder87x/AdderUSB is equivalent to Adder
> > > > >  - EVB64260_750CX    is equivalent to EVB64260
> > > > > 
> > > > > I also notice
> > > > >  - Lite5200           is equivalent to icecube_5200
> > > > >  - Lite5200_LOWBOOT   is equivalent to icecube_5200_LOWBOOT
> > > > >  - Lite5200_LOWBOOT08 is equivalent to icecube_5200_LOWBOOT08
> > > > > But I am keeping them.
> > > > > (Wolfgang suggested to do so because Lite5200* are referenced
> > > > > in misc documents.)
> > > > > 
> > > > > Signed-off-by: Masahiro Yamada <yamada.m at jp.panasonic.com>
> > > > 
> > > > I wonder (i.e., this is an open question) whether we should delete
> > > > entries for different hardware just because they happen produce
> > > > identical binaries.
> > > 
> > > In my option, we should not create multiple entries
> > > pointing to the same config header.
> > > 
> > > We are already using single entry for different boards.
> > > (In such a case, a wildcard character "x" is often used
> > > but it is not must.)
> > > For example, the entry "zynq_zc70x" is used for
> > > both "Zynq ZC702" and "Zynq ZC706" board.
> > > They are definitely different boards but the difference is quite
> > > small. So we can use the same configuration for the two.
> > > 
> > > 
> > > In the case of this patch,
> > > (I am not familiar with "ep8248" board, but I guess)
> > > ep8248 and ep8248E are different, but probably similar board.
> > > 
> > > So we can use the common entry "ep8248" for them.
> > > And "ep8248" means  "ep8248 boards family",
> > > not "exactly ep8248 board".
> > 
> > I agreed then boards.cfg ntries which point to the same config header
> > *and* have the same config options in boards.cfg could be merged.
> > 
> > However, as you point out, and I agree, that some boards are
> > *probably* similar enough to be merged, this "probably" shows that we
> > do not know for sure the intent of the board maintainer.
> > 
> > Besides, we do not know which build procedure or script is out there
> > which expects one board name or the other; merging entries would
> > disrupt those procedures, so I want to be sure we are doing the right
> > thing there.
> > 
> > Therefore, I would defer the decision of merging similar entries to the
> > board maintainer(s), who is/are supposed to know best about this; at
> > least, I would suggest to CC: them so that they can either Ack or Nak
> > as they see fit.
> 
> I had already done this.
> 
> Please read this thread:
> http://patchwork.ozlabs.org/patch/307941/
> 
> All boards I am touching in this patch are surely unmaintained.
> (So we cannot ask the reason why they added multiple entries.)
> 
> I tried to contact to their maintainers but all mails have been bouncing.
> 
> So I dropped Cc: tag when I posted v4.
> Otherwise, I would get delivery failure notification mails
> from STMP again and again.

Sorry for missing the maintainers point -- as I had to catch up, I had
not read the whole patch series ML history.

Still, this leaves the fact of possibly breaking scripts out there by
removing an existing boards.cfg entry.

Also, Wolfgang's comment on the fact we're talking about configuration
makes me realize that even binary-identical builds might behave
differently on different hardware even though the software is
configured identically.

In the end, I tend to think that the only drawback of having similar
entries is to U-Boot architecture custodians and (some) developers,
when we do a 'MAKEALL -a' or similar command, as it possibly builds a
few more boards than we might need.

For ARM, the cost of the 4 entries in boards.cfg which could perhaps be
removed is about 1% of the total 360 which I build routinely; as far as
absolute time is concerned, that's less than 30 seconds.

I think this small benefit is not worth it. Either we remove the orphan
boards entirely since we know they have no maintainer, or we keep them
in all their variants.

> Best Regards
> Masahiro Yamada

Amicalement,
-- 
Albert.