[PATCH 04/17] bsp/arm: Add linker symbol bsp_processor_count
chrisj at rtems.org
Thu Mar 13 22:45:26 UTC 2014
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
> 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.
More information about the devel