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.
We provide two BSP names so that a user can install two BSP libraries.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
