Re: [PATCH] score: Unify
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
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
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
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
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
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
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
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 _RTEMS_SCORE_ATOMIC_CP
Re: [PATCH] score: Unify CORE mutex seize/surrender
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
On 28/09/2016 19:20, Pavel Pisa wrote: On Wednesday 28 of September 2016 11:06:19 Sebastian Huber wrote: 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. I am fine with changing the name. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Unify CORE mutex seize/surrender
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
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
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
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
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
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( &queue_context ); > status = _CORE_recursive_mutex_Seize ( > &the_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(&queue_context.Lock_context.Lock_context); > status = _CORE_recursive_mutex_Surrender( > &the_networkSemaphore->Core_control.Mutex.Recursive, > + CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS, > _Thread_Executing, > &queue_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( > &the_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( > &the_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( > &the_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( > &the_mutex->Mutex.Recursive, > +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS, > executing, > &queue_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( > &the_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( > &the_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
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( &queue_context ); status = _CORE_recursive_mutex_Seize ( &the_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(&queue_context.Lock_context.Lock_context); status = _CORE_recursive_mutex_Surrender( &the_networkSemaphore->Core_control.Mutex.Recursive, + CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS, _Thread_Executing, &queue_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( &the_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( &the_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( &the_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( &the_mutex->Mutex.Recursive, +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS, executing, &queue_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( &the_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( &the_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( &the_semaphore->Core_control.Mutex.Recursive, +CORE_MUTEX_TQ_PRIORITY_INHERIT_OPERATIONS, executing, &queue_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_Sur