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

[Joel Sherrill]

Ralf,

AFAIK these rules have never been written down or
mentioned in any previous code review. For sure not
on this code. I am not arguing just trying to prevent
this in the future.

Would you mind adding the rules to
http://www.rtems.org/wiki/index.php/Coding_Conventions?

There are also empty sections on Makefile.am and configure.ac
recommendations which you are the appropriate person to
fill in.

Thanks.

--joel

On 5/1/2013 10:10 AM, Thomas Doerfler wrote:
> 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
>>
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985