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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
