Re: [PATCH] score: Unify

2023-05-25 Thread Chris Johns 
On 26/5/2023 1:38 pm, Andy wrote:
> 
> If you need my reply, I am ok to switch to BSD-2-Clause license. 
> 

Thank you and thank you for letting us know. :)

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

2023-05-25 Thread Chris Johns 
On 25/5/2023 3:54 pm, Sebastian Huber wrote:
> On 25.05.23 03:40, Kinsey Moore wrote:> Is there any reason this isn't just
> being moved to a shared directory if
>> they're all being made identical?
> 
> Initially, they were all identical. We already have a shared implementation
> 
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/cpustdatomic.h
> 
> The CPU port specific  allows a custom implementation
> if needed. I would keep this ability.
> 

Why not just add the file back if it is needed when it is needed and then remove
it once it is not?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

2023-05-25 Thread Chris Johns 
On 25/5/2023 3:51 pm, Sebastian Huber wrote:
> 
> 
> On 25.05.23 02:11, Chris Johns wrote:
>> On 24/5/2023 11:00 pm, Sebastian Huber wrote:
>>> All CPU ports use the same file.
>>> ---
>>>   .../aarch64/include/rtems/score/cpuatomic.h   |  8 ++---
>>>   .../cpu/arm/include/rtems/score/cpuatomic.h   | 11 +-
>>>   .../cpu/bfin/include/rtems/score/cpuatomic.h  | 36 ---
>>>   .../cpu/i386/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../cpu/lm32/include/rtems/score/cpuatomic.h  | 36 ---
>>>   .../cpu/m68k/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../include/rtems/score/cpuatomic.h   |  7 ++--
>>>   .../cpu/mips/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../cpu/moxie/include/rtems/score/cpuatomic.h | 11 +-
>>>   .../cpu/nios2/include/rtems/score/cpuatomic.h | 11 +-
>>>   .../cpu/or1k/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../powerpc/include/rtems/score/cpuatomic.h   | 11 +-
>>>   .../cpu/riscv/include/rtems/score/cpuatomic.h | 33 +++--
>>>   .../cpu/sh/include/rtems/score/cpuatomic.h    | 36 ---
>>>   .../cpu/sparc/include/rtems/score/cpuatomic.h |  7 ++--
>>>   .../sparc64/include/rtems/score/cpuatomic.h   | 11 +-
>>>   .../cpu/v850/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../x86_64/include/rtems/score/cpuatomic.h    | 36 ---
>>>   18 files changed, 261 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> index ed8091d73c..772d496741 100644
>>> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> @@ -3,14 +3,14 @@
>>>   /**
>>>    * @file
>>>    *
>>> - * @ingroup RTEMSScoreCPU
>>> + * @ingroup RTEMSScoreAtomicCPU
>>>    *
>>> - * @brief AArch64 Atomics support
>>> + * @brief This header file provides interfaces of the atomic operations
>>> + *   implementation using functions provided by the C11/C++11.
>>>    */
>>>     /*
>>> - * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
>>> - * Written by Kinsey Moore
>>> + * Copyright (C) 2012, 2013 Deng Hengyi
>> Is this change correct?
> 
> Yes, the file contains no copyrightable content from OAR. It hardly contains 
> any
> copyrightable content at all.

Thanks

>>>    *
>>>    * Redistribution and use in source and binary forms, with or without
>>>    * modification, are permitted provided that the following conditions
>>> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> index 01bb99cda3..772d496741 100644
>>> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> @@ -1,7 +1,16 @@
>>>   /* SPDX-License-Identifier: BSD-2-Clause */
>>>   +/**
>>> + * @file
>>> + *
>>> + * @ingroup RTEMSScoreAtomicCPU
>>> + *
>>> + * @brief This header file provides interfaces of the atomic operations
>>> + *   implementation using functions provided by the C11/C++11.
>>> + */
>>> +
>>>   /*
>>> - * COPYRIGHT (c) 2012-2013 Deng Hengyi.
>>> + * Copyright (C) 2012, 2013 Deng Hengyi
>> Why are these lines changing? Can we edit this as the license clearly states 
>> it
>> must be retained as is?
> 
> We have a copyright line template:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#copyright-and-license-block
> 
> Independent of this, it seems we didn't have a permission from Deng Hengyi to
> switch to BSD-2-Clause license:
> 
> https://devel.rtems.org/ticket/3053
> 

Ah OK. I was not wanting to open any rabbit holes. I was just wanting to have
something listed.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

2023-05-24 Thread Sebastian Huber 
On 25.05.23 03:40, Kinsey Moore wrote:> Is there any reason this isn't 
just being moved to a shared directory if

they're all being made identical?


Initially, they were all identical. We already have a shared implementation

https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/cpustdatomic.h

The CPU port specific  allows a custom 
implementation if needed. I would keep this ability.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

2023-05-24 Thread Sebastian Huber 



On 25.05.23 02:11, Chris Johns wrote:

On 24/5/2023 11:00 pm, Sebastian Huber wrote:

All CPU ports use the same file.
---
  .../aarch64/include/rtems/score/cpuatomic.h   |  8 ++---
  .../cpu/arm/include/rtems/score/cpuatomic.h   | 11 +-
  .../cpu/bfin/include/rtems/score/cpuatomic.h  | 36 ---
  .../cpu/i386/include/rtems/score/cpuatomic.h  | 11 +-
  .../cpu/lm32/include/rtems/score/cpuatomic.h  | 36 ---
  .../cpu/m68k/include/rtems/score/cpuatomic.h  | 11 +-
  .../include/rtems/score/cpuatomic.h   |  7 ++--
  .../cpu/mips/include/rtems/score/cpuatomic.h  | 11 +-
  .../cpu/moxie/include/rtems/score/cpuatomic.h | 11 +-
  .../cpu/nios2/include/rtems/score/cpuatomic.h | 11 +-
  .../cpu/or1k/include/rtems/score/cpuatomic.h  | 11 +-
  .../powerpc/include/rtems/score/cpuatomic.h   | 11 +-
  .../cpu/riscv/include/rtems/score/cpuatomic.h | 33 +++--
  .../cpu/sh/include/rtems/score/cpuatomic.h| 36 ---
  .../cpu/sparc/include/rtems/score/cpuatomic.h |  7 ++--
  .../sparc64/include/rtems/score/cpuatomic.h   | 11 +-
  .../cpu/v850/include/rtems/score/cpuatomic.h  | 11 +-
  .../x86_64/include/rtems/score/cpuatomic.h| 36 ---
  18 files changed, 261 insertions(+), 48 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
index ed8091d73c..772d496741 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
@@ -3,14 +3,14 @@
  /**
   * @file
   *
- * @ingroup RTEMSScoreCPU
+ * @ingroup RTEMSScoreAtomicCPU
   *
- * @brief AArch64 Atomics support
+ * @brief This header file provides interfaces of the atomic operations
+ *   implementation using functions provided by the C11/C++11.
   */
  
  /*

- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
- * Written by Kinsey Moore
+ * Copyright (C) 2012, 2013 Deng Hengyi

Is this change correct?


Yes, the file contains no copyrightable content from OAR. It hardly 
contains any copyrightable content at all.





   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h 
b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
index 01bb99cda3..772d496741 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
@@ -1,7 +1,16 @@
  /* SPDX-License-Identifier: BSD-2-Clause */
  
+/**

+ * @file
+ *
+ * @ingroup RTEMSScoreAtomicCPU
+ *
+ * @brief This header file provides interfaces of the atomic operations
+ *   implementation using functions provided by the C11/C++11.
+ */
+
  /*
- * COPYRIGHT (c) 2012-2013 Deng Hengyi.
+ * Copyright (C) 2012, 2013 Deng Hengyi

Why are these lines changing? Can we edit this as the license clearly states it
must be retained as is?


We have a copyright line template:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#copyright-and-license-block

Independent of this, it seems we didn't have a permission from Deng 
Hengyi to switch to BSD-2-Clause license:


https://devel.rtems.org/ticket/3053


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

2023-05-24 Thread Kinsey Moore 
Is there any reason this isn't just being moved to a shared directory if
they're all being made identical?

On Wed, May 24, 2023 at 7:11 PM Chris Johns  wrote:

> On 24/5/2023 11:00 pm, Sebastian Huber wrote:
> > All CPU ports use the same file.
>
> > - * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
> > - * Written by Kinsey Moore 
> > + * Copyright (C) 2012, 2013 Deng Hengyi
>
> Is this change correct?
>

The file has absolutely trivial contents, so whether or not it matters I'm
willing to approve of the change if it actually provides some improvement
beyond making all the files identical. I don't see a point to making them
homogeneous as the sole change.

Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

2023-05-24 Thread Chris Johns 
On 24/5/2023 11:00 pm, Sebastian Huber wrote:
> All CPU ports use the same file.
> ---
>  .../aarch64/include/rtems/score/cpuatomic.h   |  8 ++---
>  .../cpu/arm/include/rtems/score/cpuatomic.h   | 11 +-
>  .../cpu/bfin/include/rtems/score/cpuatomic.h  | 36 ---
>  .../cpu/i386/include/rtems/score/cpuatomic.h  | 11 +-
>  .../cpu/lm32/include/rtems/score/cpuatomic.h  | 36 ---
>  .../cpu/m68k/include/rtems/score/cpuatomic.h  | 11 +-
>  .../include/rtems/score/cpuatomic.h   |  7 ++--
>  .../cpu/mips/include/rtems/score/cpuatomic.h  | 11 +-
>  .../cpu/moxie/include/rtems/score/cpuatomic.h | 11 +-
>  .../cpu/nios2/include/rtems/score/cpuatomic.h | 11 +-
>  .../cpu/or1k/include/rtems/score/cpuatomic.h  | 11 +-
>  .../powerpc/include/rtems/score/cpuatomic.h   | 11 +-
>  .../cpu/riscv/include/rtems/score/cpuatomic.h | 33 +++--
>  .../cpu/sh/include/rtems/score/cpuatomic.h| 36 ---
>  .../cpu/sparc/include/rtems/score/cpuatomic.h |  7 ++--
>  .../sparc64/include/rtems/score/cpuatomic.h   | 11 +-
>  .../cpu/v850/include/rtems/score/cpuatomic.h  | 11 +-
>  .../x86_64/include/rtems/score/cpuatomic.h| 36 ---
>  18 files changed, 261 insertions(+), 48 deletions(-)
> 
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h 
> b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
> index ed8091d73c..772d496741 100644
> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
> @@ -3,14 +3,14 @@
>  /**
>   * @file
>   *
> - * @ingroup RTEMSScoreCPU
> + * @ingroup RTEMSScoreAtomicCPU
>   *
> - * @brief AArch64 Atomics support
> + * @brief This header file provides interfaces of the atomic operations
> + *   implementation using functions provided by the C11/C++11.
>   */
>  
>  /*
> - * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
> - * Written by Kinsey Moore 
> + * Copyright (C) 2012, 2013 Deng Hengyi

Is this change correct?

>   *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h 
> b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
> index 01bb99cda3..772d496741 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
> @@ -1,7 +1,16 @@
>  /* SPDX-License-Identifier: BSD-2-Clause */
>  
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreAtomicCPU
> + *
> + * @brief This header file provides interfaces of the atomic operations
> + *   implementation using functions provided by the C11/C++11.
> + */
> +
>  /*
> - * COPYRIGHT (c) 2012-2013 Deng Hengyi.
> + * Copyright (C) 2012, 2013 Deng Hengyi

Why are these lines changing? Can we edit this as the license clearly states it
must be retained as is?

>   *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
> diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h 
> b/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
> index 598ee76b20..772d496741 100644
> --- a/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
> +++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
> @@ -1,9 +1,37 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreAtomicCPU
> + *
> + * @brief This header file provides interfaces of the atomic operations
> + *   implementation using functions provided by the C11/C++11.
> + */
> +
>  /*
> - * COPYRIGHT (c) 2012-2013 Deng Hengyi.
> + * Copyright (C) 2012, 2013 Deng Hengyi
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED

[PATCH] score: Unify

2023-05-24 Thread Sebastian Huber 
All CPU ports use the same file.
---
 .../aarch64/include/rtems/score/cpuatomic.h   |  8 ++---
 .../cpu/arm/include/rtems/score/cpuatomic.h   | 11 +-
 .../cpu/bfin/include/rtems/score/cpuatomic.h  | 36 ---
 .../cpu/i386/include/rtems/score/cpuatomic.h  | 11 +-
 .../cpu/lm32/include/rtems/score/cpuatomic.h  | 36 ---
 .../cpu/m68k/include/rtems/score/cpuatomic.h  | 11 +-
 .../include/rtems/score/cpuatomic.h   |  7 ++--
 .../cpu/mips/include/rtems/score/cpuatomic.h  | 11 +-
 .../cpu/moxie/include/rtems/score/cpuatomic.h | 11 +-
 .../cpu/nios2/include/rtems/score/cpuatomic.h | 11 +-
 .../cpu/or1k/include/rtems/score/cpuatomic.h  | 11 +-
 .../powerpc/include/rtems/score/cpuatomic.h   | 11 +-
 .../cpu/riscv/include/rtems/score/cpuatomic.h | 33 +++--
 .../cpu/sh/include/rtems/score/cpuatomic.h| 36 ---
 .../cpu/sparc/include/rtems/score/cpuatomic.h |  7 ++--
 .../sparc64/include/rtems/score/cpuatomic.h   | 11 +-
 .../cpu/v850/include/rtems/score/cpuatomic.h  | 11 +-
 .../x86_64/include/rtems/score/cpuatomic.h| 36 ---
 18 files changed, 261 insertions(+), 48 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
index ed8091d73c..772d496741 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
@@ -3,14 +3,14 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreCPU
+ * @ingroup RTEMSScoreAtomicCPU
  *
- * @brief AArch64 Atomics support
+ * @brief This header file provides interfaces of the atomic operations
+ *   implementation using functions provided by the C11/C++11.
  */
 
 /*
- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
- * Written by Kinsey Moore 
+ * Copyright (C) 2012, 2013 Deng Hengyi
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h 
b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
index 01bb99cda3..772d496741 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
@@ -1,7 +1,16 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreAtomicCPU
+ *
+ * @brief This header file provides interfaces of the atomic operations
+ *   implementation using functions provided by the C11/C++11.
+ */
+
 /*
- * COPYRIGHT (c) 2012-2013 Deng Hengyi.
+ * Copyright (C) 2012, 2013 Deng Hengyi
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h 
b/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
index 598ee76b20..772d496741 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
@@ -1,9 +1,37 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreAtomicCPU
+ *
+ * @brief This header file provides interfaces of the atomic operations
+ *   implementation using functions provided by the C11/C++11.
+ */
+
 /*
- * COPYRIGHT (c) 2012-2013 Deng Hengyi.
+ * Copyright (C) 2012, 2013 Deng Hengyi
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
  */
 
 #ifndef

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Chris Johns 

On 28/09/2016 18:38, Pavel Pisa wrote:

And even rtems_* API should include mutex operations.
It is clear and it is not necessary to complicate
documentation then what is allowed and what is not
with each semaphore flags combination.


I am fine with adding a mutex API to the Classic API. The current mutex 
interface would need to be kept for a release or two before we could 
remove it if it ever is.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Pavel Pisa 
Hello Sebastian,

On Wednesday 28 of September 2016 11:06:19 Sebastian Huber wrote:
> On 28/09/16 10:47, Sebastian Huber wrote:
> > On 28/09/16 10:38, Pavel Pisa wrote:
> >> Hello Sebastian and Gedare,
> >>
> >> I cannot hold myself to not express my opinion there.
> >>
> >> On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> >>> On 27/09/16 16:59, Gedare Bloom wrote:
>  A mostly unrelated question: why do we have two different
>  _Semaphore_Get functions, one static in score/src/semaphore.c and the
>  other inlined from semimpl.h?
> >>>
> >>> Yes, this is a bit confusing. One is part of the Classic API, the other
> >>> is for the self-contained semaphores.
> >>
> >> what is the reason to name these self-contained semaphores.
> >
> > the name "self-contained" is used for objects which work with a user
> > supplied storage.  For example:
> >
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib
> >/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06
> >fd6;hb=HEAD
> >
> >
> > In contrast to the Classic and POSIX objects which work with a kernel
> > supplied storage which is accessed via the object identifier.
> >
> > In the context of the Newlib  a "semaphore" is a counting
> > semaphore.
>
> In case the name "self-contained" is confusing for this purpose, then I
> am happy to replace it with a better alternative.

No, I like self-contained, I have no problem with that. It describes
how it works. I have problem with SEMPAHORE part because
it associates for me with IPC/inter thread even delivery, producer
consumer pattern. Not mutual exclusion of enter to given code.

Excuse for confussing specification of the naming note.

Best wishes,

 Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Sebastian Huber 

On 28/09/16 10:47, Sebastian Huber wrote:

On 28/09/16 10:38, Pavel Pisa wrote:

Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:

On 27/09/16 16:59, Gedare Bloom wrote:

A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?

Yes, this is a bit confusing. One is part of the Classic API, the other
is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.


the name "self-contained" is used for objects which work with a user 
supplied storage.  For example:


https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06fd6;hb=HEAD 



In contrast to the Classic and POSIX objects which work with a kernel 
supplied storage which is accessed via the object identifier.


In the context of the Newlib  a "semaphore" is a counting 
semaphore.


In case the name "self-contained" is confusing for this purpose, then I 
am happy to replace it with a better alternative.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Sebastian Huber 

On 28/09/16 10:38, Pavel Pisa wrote:

Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:

On 27/09/16 16:59, Gedare Bloom wrote:

A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?

Yes, this is a bit confusing. One is part of the Classic API, the other
is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.


the name "self-contained" is used for objects which work with a user 
supplied storage.  For example:


https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06fd6;hb=HEAD

In contrast to the Classic and POSIX objects which work with a kernel 
supplied storage which is accessed via the object identifier.


In the context of the Newlib  a "semaphore" is a counting 
semaphore.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-28 Thread Pavel Pisa 
Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> On 27/09/16 16:59, Gedare Bloom wrote:
> > A mostly unrelated question: why do we have two different
> > _Semaphore_Get functions, one static in score/src/semaphore.c and the
> > other inlined from semimpl.h?
>
> Yes, this is a bit confusing. One is part of the Classic API, the other
> is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.
If they cannot be used as signaling mechanism between threads,
then they should be called mutexes to clearly state,
that the only valid use is initialize it as full,
gain and release it from the same thread.

For me, even use of simple, full binary etc.. semaphores
in the classic RTEMS API is a problem. There is semaphore
and mutex and each has different semantic and rules.

I understand, that historically semaphore has more meaning
as the way to pass only one task or limited number of tasks
to given part of the road, but today meaning is settled.

So if the self-contained x cannot be used to signal event
between threads then it is mutex. If there is plan to
use self-contained x even like futex/conditional variable
etc., then situation is more complex and it has reason
to have some naming layer working with semaphore or futex
stem but programmer should get clear mutex named primitives
at the end. Which is what POSIX does. Linux kernel internal
APIs cured this confusion some time ago as well.

And even rtems_* API should include mutex operations.
It is clear and it is not necessary to complicate
documentation then what is allowed and what is not
with each semaphore flags combination.

Best wishes,

  Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-27 Thread Sebastian Huber 

On 27/09/16 16:59, Gedare Bloom wrote:

A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?


Yes, this is a bit confusing. One is part of the Classic API, the other 
is for the self-contained semaphores.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

2016-09-27 Thread Gedare Bloom 
OK. A mostly unrelated question: why do we have two different
_Semaphore_Get functions, one static in score/src/semaphore.c and the
other inlined from semimpl.h?

On Tue, Sep 27, 2016 at 9:25 AM, Sebastian Huber
 wrote:
> Use the Thread_Control::resource_count for the no protocol mutexes.
> Merge the no protocol and priority inherit CORE mutex seize/surrender
> operations.
> ---
>  cpukit/libnetworking/rtems/rtems_glue.c  |  2 +
>  cpukit/posix/src/mutexlocksupp.c |  3 +-
>  cpukit/posix/src/mutexunlock.c   |  3 +-
>  cpukit/rtems/src/semobtain.c |  3 +-
>  cpukit/rtems/src/semrelease.c|  4 +-
>  cpukit/score/include/rtems/score/coremuteximpl.h | 93 
> ++--
>  cpukit/score/src/apimutexlock.c  |  1 +
>  cpukit/score/src/apimutexunlock.c|  1 +
>  8 files changed, 18 insertions(+), 92 deletions(-)
>
> diff --git a/cpukit/libnetworking/rtems/rtems_glue.c 
> b/cpukit/libnetworking/rtems/rtems_glue.c
> index 9a7f82f..46f8765 100644
> --- a/cpukit/libnetworking/rtems/rtems_glue.c
> +++ b/cpukit/libnetworking/rtems/rtems_glue.c
> @@ -379,6 +379,7 @@ rtems_bsdnet_semaphore_obtain (void)
> _Thread_queue_Context_set_no_timeout( _context );
> status = _CORE_recursive_mutex_Seize (
> _networkSemaphore->Core_control.Mutex.Recursive,
> +   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
> _Thread_Executing,
> true,   /* wait */
> _CORE_recursive_mutex_Seize_nested,
> @@ -412,6 +413,7 @@ rtems_bsdnet_semaphore_release (void)
> _ISR_lock_ISR_disable(_context.Lock_context.Lock_context);
> status = _CORE_recursive_mutex_Surrender(
> _networkSemaphore->Core_control.Mutex.Recursive,
> +   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
> _Thread_Executing,
> _context
> );
> diff --git a/cpukit/posix/src/mutexlocksupp.c 
> b/cpukit/posix/src/mutexlocksupp.c
> index 1da6238..ea4c4e3 100644
> --- a/cpukit/posix/src/mutexlocksupp.c
> +++ b/cpukit/posix/src/mutexlocksupp.c
> @@ -76,7 +76,7 @@ int _POSIX_Mutex_Lock_support(
>);
>break;
>  case POSIX_MUTEX_NO_PROTOCOL:
> -  status = _CORE_recursive_mutex_Seize_no_protocol(
> +  status = _CORE_recursive_mutex_Seize(
>  _mutex->Mutex.Recursive,
>  POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
>  executing,
> @@ -89,6 +89,7 @@ int _POSIX_Mutex_Lock_support(
>_Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
>status = _CORE_recursive_mutex_Seize(
>  _mutex->Mutex.Recursive,
> +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
>  executing,
>  wait,
>  _POSIX_Mutex_Lock_nested,
> diff --git a/cpukit/posix/src/mutexunlock.c b/cpukit/posix/src/mutexunlock.c
> index 3144314..c15f7e6 100644
> --- a/cpukit/posix/src/mutexunlock.c
> +++ b/cpukit/posix/src/mutexunlock.c
> @@ -53,7 +53,7 @@ int pthread_mutex_unlock(
>);
>break;
>  case POSIX_MUTEX_NO_PROTOCOL:
> -  status = _CORE_recursive_mutex_Surrender_no_protocol(
> +  status = _CORE_recursive_mutex_Surrender(
>  _mutex->Mutex.Recursive,
>  POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
>  executing,
> @@ -64,6 +64,7 @@ int pthread_mutex_unlock(
>_Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
>status = _CORE_recursive_mutex_Surrender(
>  _mutex->Mutex.Recursive,
> +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
>  executing,
>  _context
>);
> diff --git a/cpukit/rtems/src/semobtain.c b/cpukit/rtems/src/semobtain.c
> index 9afef54..b81612e 100644
> --- a/cpukit/rtems/src/semobtain.c
> +++ b/cpukit/rtems/src/semobtain.c
> @@ -75,6 +75,7 @@ rtems_status_code rtems_semaphore_obtain(
>  case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
>status = _CORE_recursive_mutex_Seize(
>  _semaphore->Core_control.Mutex.Recursive,
> +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
>  executing,
>  wait,
>  _CORE_recursive_mutex_Seize_nested,
> @@ -91,7 +92,7 @@ rtems_status_code rtems_semaphore_obtain(
>);
>break;
>  case SEMAPHORE_VARIANT_MUTEX_NO_PROTOCOL:
> -  status = _CORE_recursive_mutex_Seize_no_protocol(
> +  status = _CORE_recursive_mutex_Seize(
>  _semaphore->Core_control.Mutex.Recursive,
>  _Semaphore_Get_operations( the_semaphore ),
>  executing,
> diff --git a/cpukit/rtems/src/semrelease.c b/cpukit/rtems/src/semrelease.c
> index 39c467d..40860a1 100644
> --- a/cpukit/rtems/src/semrelease.c
> +++ b/cpukit/rtems/src/semrelease.c
> @@ -52,6 +52,7 @@ rtems_status_code rtems_semaphore_release( rtems_id id )
>  case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
>status =

[PATCH] score: Unify CORE mutex seize/surrender

2016-09-27 Thread Sebastian Huber 
Use the Thread_Control::resource_count for the no protocol mutexes.
Merge the no protocol and priority inherit CORE mutex seize/surrender
operations.
---
 cpukit/libnetworking/rtems/rtems_glue.c  |  2 +
 cpukit/posix/src/mutexlocksupp.c |  3 +-
 cpukit/posix/src/mutexunlock.c   |  3 +-
 cpukit/rtems/src/semobtain.c |  3 +-
 cpukit/rtems/src/semrelease.c|  4 +-
 cpukit/score/include/rtems/score/coremuteximpl.h | 93 ++--
 cpukit/score/src/apimutexlock.c  |  1 +
 cpukit/score/src/apimutexunlock.c|  1 +
 8 files changed, 18 insertions(+), 92 deletions(-)

diff --git a/cpukit/libnetworking/rtems/rtems_glue.c 
b/cpukit/libnetworking/rtems/rtems_glue.c
index 9a7f82f..46f8765 100644
--- a/cpukit/libnetworking/rtems/rtems_glue.c
+++ b/cpukit/libnetworking/rtems/rtems_glue.c
@@ -379,6 +379,7 @@ rtems_bsdnet_semaphore_obtain (void)
_Thread_queue_Context_set_no_timeout( _context );
status = _CORE_recursive_mutex_Seize (
_networkSemaphore->Core_control.Mutex.Recursive,
+   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
_Thread_Executing,
true,   /* wait */
_CORE_recursive_mutex_Seize_nested,
@@ -412,6 +413,7 @@ rtems_bsdnet_semaphore_release (void)
_ISR_lock_ISR_disable(_context.Lock_context.Lock_context);
status = _CORE_recursive_mutex_Surrender(
_networkSemaphore->Core_control.Mutex.Recursive,
+   CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
_Thread_Executing,
_context
);
diff --git a/cpukit/posix/src/mutexlocksupp.c b/cpukit/posix/src/mutexlocksupp.c
index 1da6238..ea4c4e3 100644
--- a/cpukit/posix/src/mutexlocksupp.c
+++ b/cpukit/posix/src/mutexlocksupp.c
@@ -76,7 +76,7 @@ int _POSIX_Mutex_Lock_support(
   );
   break;
 case POSIX_MUTEX_NO_PROTOCOL:
-  status = _CORE_recursive_mutex_Seize_no_protocol(
+  status = _CORE_recursive_mutex_Seize(
 _mutex->Mutex.Recursive,
 POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
 executing,
@@ -89,6 +89,7 @@ int _POSIX_Mutex_Lock_support(
   _Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
   status = _CORE_recursive_mutex_Seize(
 _mutex->Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 wait,
 _POSIX_Mutex_Lock_nested,
diff --git a/cpukit/posix/src/mutexunlock.c b/cpukit/posix/src/mutexunlock.c
index 3144314..c15f7e6 100644
--- a/cpukit/posix/src/mutexunlock.c
+++ b/cpukit/posix/src/mutexunlock.c
@@ -53,7 +53,7 @@ int pthread_mutex_unlock(
   );
   break;
 case POSIX_MUTEX_NO_PROTOCOL:
-  status = _CORE_recursive_mutex_Surrender_no_protocol(
+  status = _CORE_recursive_mutex_Surrender(
 _mutex->Mutex.Recursive,
 POSIX_MUTEX_NO_PROTOCOL_TQ_OPERATIONS,
 executing,
@@ -64,6 +64,7 @@ int pthread_mutex_unlock(
   _Assert( the_mutex->protocol == POSIX_MUTEX_PRIORITY_INHERIT );
   status = _CORE_recursive_mutex_Surrender(
 _mutex->Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 _context
   );
diff --git a/cpukit/rtems/src/semobtain.c b/cpukit/rtems/src/semobtain.c
index 9afef54..b81612e 100644
--- a/cpukit/rtems/src/semobtain.c
+++ b/cpukit/rtems/src/semobtain.c
@@ -75,6 +75,7 @@ rtems_status_code rtems_semaphore_obtain(
 case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
   status = _CORE_recursive_mutex_Seize(
 _semaphore->Core_control.Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 wait,
 _CORE_recursive_mutex_Seize_nested,
@@ -91,7 +92,7 @@ rtems_status_code rtems_semaphore_obtain(
   );
   break;
 case SEMAPHORE_VARIANT_MUTEX_NO_PROTOCOL:
-  status = _CORE_recursive_mutex_Seize_no_protocol(
+  status = _CORE_recursive_mutex_Seize(
 _semaphore->Core_control.Mutex.Recursive,
 _Semaphore_Get_operations( the_semaphore ),
 executing,
diff --git a/cpukit/rtems/src/semrelease.c b/cpukit/rtems/src/semrelease.c
index 39c467d..40860a1 100644
--- a/cpukit/rtems/src/semrelease.c
+++ b/cpukit/rtems/src/semrelease.c
@@ -52,6 +52,7 @@ rtems_status_code rtems_semaphore_release( rtems_id id )
 case SEMAPHORE_VARIANT_MUTEX_INHERIT_PRIORITY:
   status = _CORE_recursive_mutex_Surrender(
 _semaphore->Core_control.Mutex.Recursive,
+CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS,
 executing,
 _context
   );
@@ -64,13 +65,12 @@ rtems_status_code rtems_semaphore_release( rtems_id id )
   );
   break;
 case SEMAPHORE_VARIANT_MUTEX_NO_PROTOCOL:
-  _CORE_recursive_mutex_Surrender_no_protocol(
+  status = _CORE_recursive_mutex_Surrender(
 _semaphore->Core_control.Mutex.Recursive,

[PATCH] score: Unify pthread and gxx_wrapper once and move to score.

2014-03-20 Thread Christian Mauderer 
From: Christian Mauderer christian.maude...@embedded-brains.de

---
 cpukit/libcsupport/src/gxx_wrappers.c   | 15 ++--
 cpukit/posix/src/pthreadonce.c  | 37 ++-
 cpukit/score/Makefile.am|  2 ++
 cpukit/score/include/rtems/score/onceimpl.h | 50 ++
 cpukit/score/preinstall.am  | 10 --
 cpukit/score/src/once.c | 55 +
 6 files changed, 118 insertions(+), 51 deletions(-)
 create mode 100644 cpukit/score/include/rtems/score/onceimpl.h
 create mode 100644 cpukit/score/src/once.c

diff --git a/cpukit/libcsupport/src/gxx_wrappers.c 
b/cpukit/libcsupport/src/gxx_wrappers.c
index 31f6254..711daa4 100644
--- a/cpukit/libcsupport/src/gxx_wrappers.c
+++ b/cpukit/libcsupport/src/gxx_wrappers.c
@@ -29,6 +29,7 @@
 #endif
 
 #include rtems/gxx_wrappers.h
+#include rtems/score/onceimpl.h
 
 #include stdlib.h
 
@@ -43,19 +44,7 @@ int rtems_gxx_once(__gthread_once_t *once, void (*func) 
(void))
 printk( gxx_wrappers: once=%x, func=%x\n, *once, func );
   #endif
 
-  if ( *(volatile __gthread_once_t *)once == 0 ) {
-rtems_mode saveMode;
-__gthread_once_t o;
-
-rtems_task_mode(RTEMS_NO_PREEMPT, RTEMS_PREEMPT_MASK, saveMode);
-if ( (o = *(volatile __gthread_once_t *)once) == 0 ) {
-  *(volatile __gthread_once_t *)once = 1;
-}
-rtems_task_mode(saveMode, RTEMS_PREEMPT_MASK, saveMode);
-if ( o == 0 )
-  (*func)();
-  }
-  return 0;
+  return _Once( once, func );
 }
 
 int rtems_gxx_key_create (__gthread_key_t *key, void (*dtor) (void *))
diff --git a/cpukit/posix/src/pthreadonce.c b/cpukit/posix/src/pthreadonce.c
index 6b8274d..295bc57 100644
--- a/cpukit/posix/src/pthreadonce.c
+++ b/cpukit/posix/src/pthreadonce.c
@@ -23,51 +23,18 @@
 #include pthread.h
 #include errno.h
 
-#include rtems/score/apimutex.h
-
-#define PTHREAD_ONCE_INIT_NOT_RUN  0
-#define PTHREAD_ONCE_INIT_RUNNING  1
-#define PTHREAD_ONCE_INIT_COMPLETE 2
+#include rtems/score/onceimpl.h
 
 int pthread_once(
   pthread_once_t  *once_control,
   void   (*init_routine)(void)
 )
 {
-  int r = 0;
-
   if ( !once_control || !init_routine )
 return EINVAL;
 
   if ( once_control-is_initialized != 1 )
 return EINVAL;
 
-  if ( once_control-init_executed != PTHREAD_ONCE_INIT_COMPLETE ) {
-_Once_Lock();
-
-/*
- * Getting to here means the once_control is locked so we have:
- *  1. The init has not run and the state is PTHREAD_ONCE_INIT_NOT_RUN.
- *  2. The init has finished and the state is PTHREAD_ONCE_INIT_RUN.
- *  3. The init is being run by this thread and the state
- * PTHREAD_ONCE_INIT_RUNNING so we are nesting. This is an error.
- */
-
-switch ( once_control-init_executed ) {
-  case PTHREAD_ONCE_INIT_NOT_RUN:
-once_control-init_executed = PTHREAD_ONCE_INIT_RUNNING;
-(*init_routine)();
-once_control-init_executed = PTHREAD_ONCE_INIT_COMPLETE;
-break;
-  case PTHREAD_ONCE_INIT_RUNNING:
-r = EINVAL;
-break;
-  default:
-break;
-}
-
-_Once_Unlock();
-  }
-
-  return r;
+  return _Once( once_control-init_executed, init_routine );
 }
diff --git a/cpukit/score/Makefile.am b/cpukit/score/Makefile.am
index 6c4293a..aeee4b6 100644
--- a/cpukit/score/Makefile.am
+++ b/cpukit/score/Makefile.am
@@ -41,6 +41,7 @@ include_rtems_score_HEADERS += include/rtems/score/isrlock.h
 include_rtems_score_HEADERS += include/rtems/score/freechain.h
 include_rtems_score_HEADERS += include/rtems/score/object.h
 include_rtems_score_HEADERS += include/rtems/score/objectimpl.h
+include_rtems_score_HEADERS += include/rtems/score/onceimpl.h
 include_rtems_score_HEADERS += include/rtems/score/percpu.h
 include_rtems_score_HEADERS += include/rtems/score/priority.h
 include_rtems_score_HEADERS += include/rtems/score/prioritybitmap.h
@@ -335,6 +336,7 @@ libscore_a_SOURCES += src/apiext.c src/chain.c 
src/chainappend.c \
 src/interr.c src/isr.c src/wkspace.c src/wkstringduplicate.c
 libscore_a_SOURCES += src/debugisownerofallocator.c
 libscore_a_SOURCES += src/profilingisrentryexit.c
+libscore_a_SOURCES += src/once.c
 
 EXTRA_DIST = src/Unlimited.txt
 
diff --git a/cpukit/score/include/rtems/score/onceimpl.h 
b/cpukit/score/include/rtems/score/onceimpl.h
new file mode 100644
index 000..ac4a394
--- /dev/null
+++ b/cpukit/score/include/rtems/score/onceimpl.h
@@ -0,0 +1,50 @@
+/**
+ * @file
+ *
+ * @ingroup ScoreOnce
+ *
+ * @brief Once API.
+ *
+ * Functions used by posix once as well as gxx_wrappers.
+ */
+
+/*
+ * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  rt...@embedded-brains.de
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+
+#ifndef _RTEMS_ONCE_H
+#define