[rtems commit] tests: atomic support for RTEMS. Uniprocessor tests for atomic ops.
gedare at rtems.org
Wed Feb 13 16:23:25 UTC 2013
On Wed, Feb 13, 2013 at 9:44 AM, Ralf Corsepius
<ralf.corsepius at rtems.org> wrote:
> On 02/08/2013 01:41 AM, Gedare Bloom wrote:
>> On Thu, Feb 7, 2013 at 5:15 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>> Module: rtems
>>> Branch: master
>>> Commit: fb9fa1537a9765eae90124e5db5770ae7a527d5e
>>> Author: WeiY <wei.a.yang at gmail.com>
>>> Date: Fri Jan 25 23:59:49 2013 +0800
>>> tests: atomic support for RTEMS. Uniprocessor tests for atomic ops.
>> The tests do not compile for sis at least. Maybe broken for other
>> targets that do not have the atomics defined?
> RTEMS doesn't compile for all targets which do not have a file named
> i.e. all targets but the powerpc and the i386.
>> In file included from
>> ../../../../../sis/lib/include/rtems/score/atomic.h:21:35: fatal
>> error: rtems/score/cpuatomic.h: No such file or directory
>> compilation terminated.
>> $> find cpukit/score -name cpuatomic.h
>> We should have some kind of stubs so that non-supported architectures
>> will compile the atomic tests.
> Well, I agree to some extend, but ...
> ... I feel this is playing with symptoms.
> The actual issue behind all this, is the atomic-API currently being
> implemented as a conditional API - This is not good.
> I an ideal world, one would not have any conditional API, but would have a
> target-independent API.
If we implement ISR_Disable/Enable wrapped routines, we can provide a
target-independent functionally correct implementation of the API. I
think the student is working on this now.
> That said, unless this issue can be resolved, IMO, all the atomic headers
> should only be installed/pre-installed, if all ops and headers are
> implemented for a specific target - ATM, this does not apply.
I think that Sebastian is attempting to figure out how to do this.
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the devel