[rtems commit] Using the generic atomic ops to implement UP mode atomic for all architectures . SMP atomic port will be later.

[Thomas Doerfler]

Hi,

I agree with Ralf: The cplusplus guard, AFAIK, can be used to make pure
C constructs, that are non-C++, interfaceable with C++ (Anyone with more
C++ knowledge: Please don't flame me too much :-) )

But the current content of the discussed header file only contains
further preprocessor stuff (+if, +include etc) and therefore has nothing
incompatible with C++.

IMHO Mechanisms like the C++ guard with "extern "C" " should be used
only when really needed. So removing it seems preferable to me.

wkr,

Thomas.

Am 01.05.2013 17:03, schrieb Gedare Bloom:
> On Wed, May 1, 2013 at 10:44 AM, Ralf Corsepius
> <ralf.corsepius at rtems.org> wrote:
>> On 05/01/2013 04:23 PM, Gedare Bloom wrote:
>>>
>>> Module:    rtems
>>> Branch:    master
>>> Commit:    9b605b28b497f398682a8ffd673f6860340957f8
>>> Changeset:
>>> http://git.rtems.org/rtems/commit/?id=9b605b28b497f398682a8ffd673f6860340957f8
>>>
>>> Author:    WeiY <wei.a.yang at gmail.com>
>>> Date:      Wed Apr 24 00:34:16 2013 +0800
>>>
>>> Using the generic atomic ops to implement UP mode atomic for all
>>> architectures. SMP atomic port will be later.
>>
>>
>>> +++ b/cpukit/score/cpu/arm/rtems/score/cpuatomic.h
>>> @@ -0,0 +1,40 @@
>>> +/**
>>> + * @file  rtems/score/cpuatomic.h
>>> + *
>>> + * This include file implements the atomic operations for arm and defines
>>> + * atomic data types which are used by the atomic operations API file.
>>> This
>>> + * file should use fixed name cpuatomic.h and should be included in
>>> atomic
>>> + * operations API file atomic.h. If the architecture works at the UP mode
>>> it
>>> + * will use a generic atomic ops using disable/enable-IRQ simulated. If
>>> the
>>> + * the architecture works at SMP mode, most of the parts of
>>> implementations
>>> + * are imported from FreeBSD kernel.
>>> + */
>>> +
>>> +#ifndef _RTEMS_SCORE_ATOMIC_CPU_H
>>> +#define _RTEMS_SCORE_ATOMIC_CPU_H
>>> +
>>> +#include <rtems/score/genericcpuatomic.h>
>>> +
>>> +#ifdef __cplusplus
>>> +extern "C" {
>>> +#endif
>>> +
>>> +/**
>>> + * @defgroup RTEMS atomic implementation
>>> + *
>>> + */
>>> +
>>> +/**@{*/
>>> +
>>> +#if !defined(RTEMS_SMP)
>>> +#include <rtems/score/genericatomicops.h>
>>> +#else
>>> +#endif
>>> +
>>> +#ifdef __cplusplus
>>> +}
>>> +#endif
>>> +
>>> +/**@}*/
>>> +#endif
>>> +/*  end of include file */
>>
>>
>> Would somebody please explain the code above?
>>
> This file splits the code for the atomic operations into two cases,
> uniprocessor and SMP. The uniprocessor (UP) generic framework disables
> and enables interrupts around the operation and can be used by any
> CPU. In SMP mode, the CPU should define the atomic operations. For the
> ARM and many other RTEMS targets, SMP mode is not supported so we do
> nothing here. In the future, the #else branch would include the atomic
> operations that are available for SMP.
> 
>> The #ifdef __cplusplus as well as the #if !defined(RTEMS_SMP)
>> should be completely superflous. If not, they'd indicate bugs elsewhere.
>>
> The C++ guard is commonly used in score headers. I don't think anyone
> has codified when it can be removed. It does seem this file does not
> need it.
> 
> The SMP mode should be left as a placeholder for when SMP support is
> added. Perhaps a #warning or even #error should be added there to
> indicate there is a problem.
> 
>> Ralf
>>
>>
>>
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
> 


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.