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

Marek Vasut
2011-09-22T08:52:45Z

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