Gsoc2012: Atomic operation for RTEMS

[Gedare Bloom]

On Fri, Jun 15, 2012 at 9:22 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
> Hi all,
>
> Now i am working on importing the atomic implementation code from
> FreeBSD kernel to Rtems. And there are some issues to be clarified.
>
> 1.What is the principle of importing the implementations from FreeBSD
> to Rtems? Should we keep the code and its style unchanging as far as
> possible? or we just refer its implementation code and change them in
> rtems style?
> 2.Whether the copyright and author information should be reserved or not?
>
Some general guidelines... If you're copying whole files/subsystems
you should keep the code/style a copy of the source (FreeBSD) as close
as possible so that you can more easily detect/apply updates in the
future. If you're having to rewrite the functions due to different
names (i.e. copying implementations) then you should probably adopt
the RTEMS style rules and eventually the code may drift from the
FreeBSD source.

As for copyright/authorship (and licensing), if you are copying code
then you need to honor the author's marks.

-Gedare

>
> 2012/6/12 yangwei weiyang <wei.a.yang at gmail.com>:
>> Hi all,
>>
>> Last week there are two issues to be solved.
>> 1. Whether the atomic specific date type is needed. After some
>> discussion i found there is no need to define those date types and
>> rtems basic date types are enough. So i have replace all those date
>> types with rtems basic date types.
>> 2. The atomic API definitions should be made static inline. After some
>> comparison with the solutions i move all the atomic definitions in
>> atomic_manager.c originally to atomic.inl. And then atomic.h include
>> the atomic.inl.
>>
>> The repository is in the github on which i have create a separate
>> branch "atomic". https://github.com/WeiY/rtems/commits/atomic.
>> Comments are welcome.
>>
>> 2012/6/6  <wei.a.yang at gmail.com>:
>>>
>>>
>>> 在 2012-6-6，11:45，Ralf Corsepius <ralf.corsepius at rtems.org> 写道：
>>>
>>>> On 06/06/2012 03:46 AM, Chris Johns wrote:
>>>>> On 6/06/12 12:33 AM, Sebastian Huber wrote:
>>>>>>
>>>>>> No, the "atomic_cpu_generic.h" should provide the type definitions for
>>>>>> reasonable architectures. It is good to have architecture specific types
>>>>>> like Atomic_Int, but I think on most architectures it will be "typedef
>>>>>> Atomic_Int int". For all architectures with straight forward type
>>>>>> definitions we can use "atomic_cpu_generic.h".
>>>>>>
>>>>>
>>>>> This is a good idea.
>>>>
>>>> What would this be useful for?
>>>>
>>>> I don't see any reasons to have typedefs for "Atomic types" on ordinal types or POSIX types, except of "API stylishness".
>>> Yeah, Ralf. You are right. I select the "Atomic type" that mostly because of the API stylishness. In fact using the basic date types which are type defined based on date types supported by program language is also ok, such as uint_32.
>>>>
>>>> More generally speaking, the only technical reason to have typedefs on ordinal types or POSIX types would be to cover "exotic" architectures, whose toolchains do not implement all of these types.
>>>>
>>>> In practice, nowadays, such architectures/toolchains are pretty rare to find.
>>>>
>>>> Ralf
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-devel mailing list
>>>> rtems-devel at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>>
>> --
>> Wei Yang
>> Best Regards
>>
>> wei.a.yang at gmail.com
>
>
>
> --
> Wei Yang
> Best Regards
>
> wei.a.yang at gmail.com
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel