About locks and concurrency rules for SMP systems

Hi, How does RTEMS handle cases where two different cores access scheduler-related functions at the same time? For ex., Can they access (or modify) the Scheduler_strong_APA_Context at the same time? Thanks

Regarding cross-reference link in docs

Hello everyone, I am writing a document page and i am getting stuck in writing reference link to different manual of docs. I tried using the .. _reference: , :ref:`refrence-link` method but it works for document in same manual but not in different manuals . And I think this is an issue in several d

Re: [PATCH] Add configuration option for single processor applications

> > That depends. I don't think the CPP will handle string concatenation > so well, so a long string like that can cause an exception to the > rule. Otherwise you would end up with something like > #ifndef CONFIGURE_MAXIMUM_PROCESSORS > #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to

Re: [rtems commit] gen_uuid.c: Fix two Unchecked return value from library errors

On 08/03/2021 21:56, Joel Sherrill wrote: Module:rtems Branch:master Commit:597e4f476568a225d14dfaff02074cf269ad62ac Changeset:http://git.rtems.org/rtems/commit/?id=597e4f476568a225d14dfaff02074cf269ad62ac Author:Ryan Long Date: Tue Mar 2 11:08:28 2021 -0500 gen_uuid.c: F

Re: About locks and concurrency rules for SMP systems

On 24/03/2021 08:07, Richi Dubey wrote: How does RTEMS handle cases where two different cores access scheduler-related functions at the same time? Each scheduler has its own lock. There are a couple of more locks involved. For ex., Can they access (or modify) the Scheduler_strong_APA_Context

[PATCH 1/2] score: Fix _CORE_ceiling_mutex_Set_priority()

We have to use a second thread queue context to acquire and release the thread wait lock. Close #4356. --- cpukit/include/rtems/score/coremuteximpl.h | 13 +++-- cpukit/rtems/src/semsetpriority.c | 3 +-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/cpukit/incl

[PATCH 2/2] rtems: Simplify rtems_semaphore_set_priority()

Do not write to the object referenced by old_priority in error paths. This is in line with other directives. --- cpukit/rtems/src/semsetpriority.c | 47 +++ 1 file changed, 22 insertions(+), 25 deletions(-) diff --git a/cpukit/rtems/src/semsetpriority.c b/cpukit/rtems

[PATCH] rld-cc: Add -target to recognised cflags

-target *-*-* flag is necessary for LLVM/Clang while cross-compiling --- rtemstoolkit/rld-cc.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/rtemstoolkit/rld-cc.cpp b/rtemstoolkit/rld-cc.cpp index bb03ff6..b424214 100644 --- a/rtemstoolkit/rld-cc.cpp +++ b/rtemstoolkit/rld-cc.cpp @@ -110,6

Re: #4328: New APIs added to POSIX Standard (2021)

Hi Dr. Joel, I've gone over the list a few times now and see a few categories shaping up: 1) Already done (In Newlib source, defined in libc.a): a) reallocarray b) qsort_r c) memmem d) strlcat / strlcpy d) wcslcat / wcslcpy *Out of this group, strlcat and strlcpy also show up in src/rtems/cpukit.

Re: [rtems commit] gen_uuid.c: Fix two Unchecked return value from library errors

I'm reverting this. I think this is in a batch that did not get tested before I worked with Ryan to correct his procedure.to ensure more testing with debug enabled. On most he has filed issues with the upstream, but as you note, this isn't the right solution so that doesn't matter here. Probably

[PATCH v2 0/2] Fix QEMU branch analysis

v2: - Revert change to ENTRIES macro in CoverageReaderQEMU.cc This patch set contains a couple of fixes for issues that were found while using covoar to analyze branch coverage in QEMU. Alex White (2): covoar/CoverageReaderQEMU: Fix infinite loop covoar/TargetBase: Fix QEMU branch info test

[PATCH v2 2/2] covoar/TargetBase: Fix QEMU branch info

The taken/not taken bit was being interpreted incorrectly. This led to branches being marked "always taken" when they were never taken. This has been fixed. --- tester/covoar/TargetBase.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tester/covoar/TargetBase.cc b/tester/

[PATCH v2 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

There was a potential that the branch info loop never terminated. This has been fixed by adding a more reliable termination condition and logging an error if it cannot find the branch target. --- tester/covoar/CoverageReaderQEMU.cc | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) dif

Recent rtems-tools patches status

Hi, Here is the status of the rtems-tools patches I have sent out over the past few weeks (an X means the latest patch revision has been reviewed): [ ] tester: Limit branch coverage percentage precision [ ] coverage: Fix option processing on FreeBSD [ ] coverage/symbol-sets.ini : Add libtrace [

Re: [rtems commit] gen_uuid.c: Fix two Unchecked return value from library errors

On Wed, Mar 24, 2021 at 7:03 AM Joel Sherrill wrote: > > I'm reverting this. > > I think this is in a batch that did not get tested before I worked > with Ryan to correct his procedure.to ensure more testing with > debug enabled. > > On most he has filed issues with the upstream, but as you note,

Re: Recent rtems-tools patches status

On Wed, Mar 24, 2021 at 7:56 AM Alex White wrote: > > Hi, > > > > Here is the status of the rtems-tools patches I have sent out over the past > few weeks (an X means the latest patch revision has been reviewed): > > > > [ ] tester: Limit branch coverage percentage precision > > [ ] coverage: Fix

Re: [PATCH 2/2] rtems: Simplify rtems_semaphore_set_priority()

these two patches look ok to me. On Wed, Mar 24, 2021 at 1:40 AM Sebastian Huber wrote: > > Do not write to the object referenced by old_priority in error paths. > This is in line with other directives. > --- > cpukit/rtems/src/semsetpriority.c | 47 +++ > 1 file chan

Re: [PATCH v2 0/2] Fix QEMU branch analysis

these two patches look ok On Wed, Mar 24, 2021 at 7:45 AM Alex White wrote: > > v2: > - Revert change to ENTRIES macro in CoverageReaderQEMU.cc > > This patch set contains a couple of fixes for issues that were found > while using covoar to analyze branch coverage in QEMU. > > Alex White (2): >

Re: #4328: New APIs added to POSIX Standard (2021)

Wow! Good work. There is a lot to digest here. Comments interspersed. I assume the spreadsheet is updated. On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce wrote: > Hi Dr. Joel, > > I've gone over the list a few times now and see a few categories shaping > up: > > 1) Already done (In Newlib source

Re: Recent rtems-tools patches status

On Wed, Mar 24, 2021 at 10:52 AM Gedare Bloom wrote: > On Wed, Mar 24, 2021 at 7:56 AM Alex White wrote: > > > > Hi, > > > > > > > > Here is the status of the rtems-tools patches I have sent out over the > past few weeks (an X means the latest patch revision has been reviewed): > > > > > > > > [

Re: [PATCH v6] cpukit/aarch64: Add ESR register decoding

On Tue, Mar 23, 2021 at 2:25 PM Alex White wrote: > > --- > .../aarch64/aarch64-exception-frame-print.c | 135 -- > 1 file changed, 125 insertions(+), 10 deletions(-) > > diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c > b/cpukit/score/cpu/aarch64/aarch64-

RE: Recent rtems-tools patches status

On Wed, Mar 24, 2021 at 11:04 AM Joel Sherrill wrote: > > > > On Wed, Mar 24, 2021 at 10:52 AM Gedare Bloom wrote: >> >> On Wed, Mar 24, 2021 at 7:56 AM Alex White wrote: >> > My plan is to resend the patches that have not been reviewed and meter >> > them out so I don’t overwhelm the list. Hop

[PATCH] covoar: Add aarch64 target

--- tester/covoar/TargetFactory.cc | 2 + tester/covoar/Target_aarch64.cc | 100 tester/covoar/Target_aarch64.h | 77 tester/covoar/wscript | 1 + 4 files changed, 180 insertions(+) create mode 100644 tester/covoar/Target_

Re: [PATCH] covoar: Add aarch64 target

On Wed, Mar 24, 2021 at 10:46 AM Alex White wrote: > > --- > tester/covoar/TargetFactory.cc | 2 + > tester/covoar/Target_aarch64.cc | 100 > tester/covoar/Target_aarch64.h | 77 > tester/covoar/wscript | 1 + > 4 files ch

Re: GSoC Project : Package Micro-python

On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom wrote: > On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan > wrote: > > > > > > Apologies for the late reply. > > > > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill wrote: > >> > >> > >> > >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom wrote: > >>> >

RE: [PATCH] covoar: Add aarch64 target

On Wed, Mar 24, 2021 at 12:25 PM Gedare Bloom wrote: > > On Wed, Mar 24, 2021 at 10:46 AM Alex White wrote: > > diff --git a/tester/covoar/Target_aarch64.cc > > b/tester/covoar/Target_aarch64.cc > > new file mode 100644 > > index 000..64472d6 > > --- /dev/null > > +++ b/tester/covoar/Target_

Re: GSoC Project : Package Micro-python

On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan wrote: > > > > On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom wrote: >> >> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan >> wrote: >> > >> > >> > Apologies for the late reply. >> > >> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill wrote: >> >> >>

Re: [PATCH] covoar: Add aarch64 target

On Wed, Mar 24, 2021 at 12:27 PM Alex White wrote: > > On Wed, Mar 24, 2021 at 12:25 PM Gedare Bloom wrote: > > > > On Wed, Mar 24, 2021 at 10:46 AM Alex White wrote: > > > diff --git a/tester/covoar/Target_aarch64.cc > > > b/tester/covoar/Target_aarch64.cc > > > new file mode 100644 > > > inde

Making Covoar More C++

Hi There has been a lot of talk about making covoar use more C++ features. It seems to be an issue on every patch. I almost replied to Gedare's comment at the bottom of a patch but decided it needed another thread: "I still struggle reviewing this codebase, in part because it is C+C++ (TM) and in

Re: Making Covoar More C++

On Wed, Mar 24, 2021 at 1:35 PM Joel Sherrill wrote: > > Hi > > There has been a lot of talk about making covoar use more C++ > features. It seems to be an issue on every patch. I almost > replied to Gedare's comment at the bottom of a patch > but decided it needed another thread: > > "I still str

Re: Making Covoar More C++

On Wed, Mar 24, 2021 at 2:42 PM Gedare Bloom wrote: > On Wed, Mar 24, 2021 at 1:35 PM Joel Sherrill wrote: > > > > Hi > > > > There has been a lot of talk about making covoar use more C++ > > features. It seems to be an issue on every patch. I almost > > replied to Gedare's comment at the bottom

Re: Making Covoar More C++

On 25/3/21 6:54 am, Joel Sherrill wrote: > > > On Wed, Mar 24, 2021 at 2:42 PM Gedare Bloom > wrote: > > On Wed, Mar 24, 2021 at 1:35 PM Joel Sherrill > wrote: > > > > Hi > > > > There has been a lot of talk about makin

Re: Making Covoar More C++

On Wed, Mar 24, 2021, 7:28 PM Chris Johns wrote: > > > On 25/3/21 6:54 am, Joel Sherrill wrote: > > > > > > On Wed, Mar 24, 2021 at 2:42 PM Gedare Bloom > > wrote: > > > > On Wed, Mar 24, 2021 at 1:35 PM Joel Sherrill > > wrote: > > >

Re: Making Covoar More C++

On 25/3/21 11:54 am, Joel Sherrill wrote: > > > On Wed, Mar 24, 2021, 7:28 PM Chris Johns > wrote: > > > > On 25/3/21 6:54 am, Joel Sherrill wrote: > > > > > > On Wed, Mar 24, 2021 at 2:42 PM Gedare Bloom > >