On 19/02/2014 3:28 am, Joel Sherrill wrote:
On 2/18/2014 10:20 AM, Gedare Bloom wrote:
On Tue, Feb 18, 2014 at 10:19 AM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:
git
On 2/18/2014 1:12 AM, Sebastian Huber wrote:
Hello Joel,
On 2014-02-17 18:08, Joel Sherrill wrote:
Hi
FWIW It may be better to not build task variables than to just return an
error. That is an entire class of capability that is not supported in
SMP. The tests for that would fail to link and could then just be
disabled from building.
I'd rather leave the tests as failing than to disable them. Eventually
they should work if task variables get fixed?
Task variables are fundamentally and conceptually broken for SMP systems.
Maybe we should remove the task variable API from RTEMS. To support SMP
we need to have a suitable alternative and there is no reason this
cannot be used in uni-processor systems. That could be mean code cannot
be written assuming task variables.
One underlying assumption is that if it isn't safe in SMP, then we need
to find a way to
"break" applications in an explicit as possible way. This encourages
application developers
to fix the issues before they find subtle bugs on target.
Should we keep APIs that are not compatible ? I say no we should not.
Keeping them means users needs to be aware of the differences and to
manage them when writing applications that may move between
uni-processor and SMP systems. If the APIs do not exist this is not a
factor. I also suspect the easiest way to this is not to use them.
To implement this we remove task variables and the pre-emption defines
for SMP builds and flag the them as deprecated in disabled SMP builds
then remove in the next release.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
