[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

On Wednesday, September 21, 2011 01:31:28 AM Scott Wood wrote:
> On 09/20/2011 04:30 PM, Marek Vasut wrote:
> > On Tuesday, September 20, 2011 11:23:01 PM Scott Wood wrote:
> >> On 09/20/2011 04:16 PM, Marek Vasut wrote:
> >>> On Tuesday, September 20, 2011 09:12:08 PM Scott Wood wrote:
> >>>> On 09/19/2011 05:31 PM, Marek Vasut wrote:
> >>>>> Then you adjust the makefile there by ifdef CONFIG_SPL_BUILD
> >>>> 
> >>>> It's not quite that simple, since different SPLs will have different
> >>>> requirements.  Board config headers will need to define symbols like
> >>>> CONFIG_SPL_FEATURE and the makefiles will use both CONFIG_SPL_BUILD
> >>>> and CONFIG_SPL_FEATURE to determine which object files to include.
> >>> 
> >>> That kind of granularity is there already too -- though on driver
> >>> level. But so far it seem sufficient.
> >> 
> >> What's wrong with using that model for arch code as well?
> >> 
> >> Note that "so far" most of the existing SPL targets have not been
> >> converted to the new spl/.
> > 
> > Right, so when you hit the problem, you fix it. No need to overengineer
> > it right away.
> 
> It seems you hit the problem already, and you're trying to add an ad hoc
> workaround rather than apply the same concept to arch code that is to be
> used with drivers.
> 
> Wanting to staying consistent and simple is not overengineering.
> 
> >> It's not about rarity (which is often misjudged, BTW).  It's about
> >> whether the model for selecting code for the SPL is additive or
> >> subtractive, and whether we have a consistent mechanism or ad hockery
> >> from the start.
> >> 
> >> In nand_spl/ it was fully additive.  I'd like to keep it that way.
> > 
> > I see your point and I disagree. I'd use the majority vote here -- most
> > of the boards need it and rare ones don't -- so why put additional
> > burden on majority in favor of minority ?
> 
> Is it really such a burden to put something like
> 
> #define CONFIG_SPL_ARCH_CPU
> 
> in your board config header? 

Yes it's a burden. It's a burden to add this to all boards but one. It makes no 
sense.

> If you end up with several things that 95%
> of targets are including, factor them out into a common header, like
> include/config_cmd_default.h.  Or have a single define that selects a
> set of defaults.  Or integrate kconfig. :-)
> 
> I don't want to get into a situation where someone has to dig around to
> find out which bits of code are included by default, and what the
> special magic is to turn them off.
> 
> -Scott