[PATCH 04/17] bsp/arm: Add linker symbol bsp_processor_count

[Chris Johns]

On 13/03/2014 9:31 pm, Sebastian Huber wrote:
> On 2014-03-13 01:20, Chris Johns wrote:
>> On 4/03/2014 8:47 pm, Ralf Kirchner wrote:
>>> Hi Chris,
>>> Yes using "enable SMP" sounds like a nice idea.
>>> Actually beeing under time pressure I needed a solution which I could
>>> get up and running quickly and easily. This is the major reason for the
>>> linker command files solution.
>>> I am sure the "enable SMP" solution also would be doable but it would
>>> have cost me time I did not have.
>>
>> Is there plans to address this ?
>>
>> My concern is the effect this approach will have on continuous testing
>> time and
>> when that is active this approach may be rejected. For example complete
>> testing, which we cannot do, would imply we test all combinations of
>> options to
>> configure. This is not feasible so we have to limit ourselves to a
>> subset and
>> in this case each BSP with and without --enable-smp would be required
>> where a
>> single BSP covers both. My point being I suspect the testing system's
>> load and
>> performance may have to be given a higher consideration over your time
>> allocation and budgeting once it is running and we know the
>> performance and
>> loading.
>
> This bsp_processor_count symbol definition is just there to provide a
> sanity check.  I you use the wrong linker command file, then you use
> some stack areas multiple times at once and this is not healthy.  Since
> the ARM uses a lot less copy and paste compared to other architectures
> it is easy to change something if someone has a better solution.

All I am suggesting is the --enable-smp selects the correct linker 
command file for the same BSP and we do not have these variants.

The saving is not needing to build each BSP variant with and without 
SMP. We have traditionally been slack with our testing of configure 
options and have tended to just test the common or normal mix of options 
each of us use. You only have to look at --enable-debug bugs and how 
long they sit before being fixed. One of the goals of continuous testing 
is to automatically test these other paths so we need to be mindful not 
to overload the system with unnecessary builds. Another goal of 
continuous testing is to help the developers by doing this testing for 
them so helping support this system to work efficiently helps us.

To me the way BSPs for SMP are configured appears inconsistent. I feel 
we should either have --enable-smp or an SMP variant of a BSP. Mixing 
things just add confusion for the user and as stated increases the 
testing work load. FWIW I personally would prefer a BSP define a default 
state and users configure away from that. In the case of a multicore 
device it defaults to SMP and the number of cores and a user configures 
to disable SMP or lower the cores for a different configuration however 
this would need a new and different build system.

>
> We provide two BSP names so that a user can install two BSP libraries.
>

You can use a different prefix and doing this has advantages.

Chris