On 17/11/2021 08:50, Moyano, Gabriel wrote:
These commits port to rtems 5 the last changes in kern_tc and timecounter
pushed by Sebastian Huber.
Additionally the last commit closes the ticket 4549, which is a clone of
2348(NTP support) for rtems 5.
From my point of view this patch set accepta
Hi Sebastian,
Thx for your quick answer.
> > These commits port to rtems 5 the last changes in kern_tc and timecounter
> > pushed by Sebastian Huber.
> > Additionally the last commit closes the ticket 4549, which is a clone of
> > 2348(NTP support) for rtems 5.
>
> From my point of view this
On 17/11/2021 11:42, gabriel.moy...@dlr.de wrote:
The patch set should have no API/ABI impact on applications.
Sorry I didn't verified if the ABI is broken. We are checking this with my team.
I think, the patch set should have no API/ABI impact on applications.
The changes are all in kern_tc.
The thread's blocked status is recorded in the thread's scheduler state,
not directly in the thread state. This prevents blocking from being
nested which violates asserts and eventually causes a crash.
---
cpukit/score/src/schedulerpriorityaffinitysmp.c | 8
1 file changed, 4 insertions(+
Hi,
For this patchset we
- Added the ability to pin/unpin a thread using affinity to the priority
SMP scheduler.
- Changed the state that was being checked in
_Scheduler_priority_affinity_SMP_Set_affinity() to be the thread's
scheduler's state. This was done because that is where the thread
---
cpukit/include/rtems/score/scheduler.h | 36
.../rtems/score/schedulerpriorityaffinitysmp.h | 4 +-
cpukit/score/src/schedulerpinusingaffinity.c | 98 ++
spec/build/cpukit/objsmp.yml | 1 +
4 files changed, 137 insertio
Split code at the end of the smpthreadpin01 test so that it could be reused
for the smpthreadpin02 test.
---
spec/build/testsuites/smptests/grp.yml | 2 +
spec/build/testsuites/smptests/smpthreadpin01.yml | 2 +-
spec/build/testsuites/smptests/smpthreadpin02.yml | 20 +
testsuit
On 17/11/2021 16:33, Ryan Long wrote:
For this patchset we
- Added the ability to pin/unpin a thread using affinity to the priority
SMP scheduler.
- Changed the state that was being checked in
_Scheduler_priority_affinity_SMP_Set_affinity() to be the thread's
scheduler's state. This was
On 11/17/2021 10:01 AM, Sebastian Huber wrote:
On 17/11/2021 16:33, Ryan Long wrote:
For this patchset we
- Added the ability to pin/unpin a thread using affinity to the priority
SMP scheduler.
- Changed the state that was being checked in
_Scheduler_priority_affinity_SMP_Set_affinity()
On 17/11/2021 16:33, Ryan Long wrote:
---
cpukit/include/rtems/score/scheduler.h | 36
.../rtems/score/schedulerpriorityaffinitysmp.h | 4 +-
cpukit/score/src/schedulerpinusingaffinity.c | 98 ++
spec/build/cpukit/objsmp.yml
On 17/11/2021 16:33, Ryan Long wrote:
The thread's blocked status is recorded in the thread's scheduler state,
not directly in the thread state. This prevents blocking from being
nested which violates asserts and eventually causes a crash.
---
cpukit/score/src/schedulerpriorityaffinitysmp.c | 8
On 17/11/2021 17:07, Ryan Long wrote:
On 11/17/2021 10:01 AM, Sebastian Huber wrote:
On 17/11/2021 16:33, Ryan Long wrote:
For this patchset we
- Added the ability to pin/unpin a thread using affinity to the priority
SMP scheduler.
- Changed the state that was being checked in
_Schedule
On 17/11/2021 09:11, Sebastian Huber wrote:
Module:rtems
Branch:master
Commit:ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
Changeset:http://git.rtems.org/rtems/commit/?id=ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
Author:Sebastian Huber
Date: Mon Oct 11 17:07:50 2021 +0200
rtems:
Hello,
for what is RTEMS_WHO_AM_I used?
grep -r RTEMS_WHO_AM_I .
./cpukit/include/rtems/rtems/object.h:#define RTEMS_WHO_AM_I
OBJECTS_WHO_AM_I
grep -r OBJECTS_WHO_AM_I .
./cpukit/include/rtems/score/object.h:#define OBJECTS_WHO_AM_I 0
./cpukit/include/rtems/rtems/object.h:#define RT
On Wed, Nov 17, 2021 at 10:42 AM Sebastian Huber
wrote:
>
> Hello,
>
> for what is RTEMS_WHO_AM_I used?
>
> grep -r RTEMS_WHO_AM_I .
> ./cpukit/include/rtems/rtems/object.h:#define RTEMS_WHO_AM_I
> OBJECTS_WHO_AM_I
>
> grep -r OBJECTS_WHO_AM_I .
> ./cpukit/include/rtems/score/object.h:#define OBJE
Ensure when both RTEMS_DEBUG is specified and pointers are large that
enough space is allocated to accomodate the Per_CPU_Control structure.
This changes the calculation to be more compositional instead of trying
to list out every permutation of options possible.
---
cpukit/include/rtems/score/per
These two OAR copyright headers are the only two in the codebase with
a format that differs from the typical OAR copyright header. This makes
all of the OAR copyright headers consistent.
---
cpukit/score/cpu/arm/include/rtems/score/cpu.h | 2 +-
cpukit/score/src/stackallocatorforidle.c | 2 +
Hi
Looks like the microblaze and aarch64 do not have bsp_specs, the
existing ones are empty, and the only build/specs reference is to
install one for an stm BSP.
Is it time to remove them?
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtem
Hi
I came across three aclocal directories on master. Is there a reason I
am missing why they are still there?
If there are no objections, I will remove them.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 16/11/2021 22:47, Chris Johns wrote:
On 16/11/21 4:27 am, Sebastian Huber wrote:
On 11/11/2021 08:02, Sebastian Huber wrote:> On 09/11/2021 13:06, Sebastian
Huber wrote:
On 09/11/2021 08:50, Sebastian Huber wrote:
On 09/11/2021 08:41, Chris Johns wrote:
We could also use something like th
On 17/11/2021 18:10, Joel Sherrill wrote:
I'm prone to change rtems_task_ident() to use RTEMS_WHO_AM_I
since that is more proper.
Yes, this sounds good. I will fix this.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
On 17/11/2021 19:13, Joel Sherrill wrote:
I came across three aclocal directories on master. Is there a reason I
am missing why they are still there?
It is just an oversight.
If there are no objections, I will remove them.
Yes, please.
--
embedded brains GmbH
Herr Sebastian HUBER
Dorniers
On 17/11/2021 19:11, Joel Sherrill wrote:
Looks like the microblaze and aarch64 do not have bsp_specs, the
existing ones are empty, and the only build/specs reference is to
install one for an stm BSP.
Is it time to remove them?
Yes, we don't need them any more. I probably forgot to remove them
On 18/11/21 3:39 am, Sebastian Huber wrote:
> On 17/11/2021 09:11, Sebastian Huber wrote:
>> Module: rtems
>> Branch: master
>> Commit: ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
>> Changeset:http://git.rtems.org/rtems/commit/?id=ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
>>
>>
>> Author: S
On 17/11/21 11:03 pm, Sebastian Huber wrote:
> On 17/11/2021 11:42, gabriel.moy...@dlr.de wrote:
>>> The patch set should have no API/ABI impact on applications.
>> Sorry I didn't verified if the ABI is broken. We are checking this with my
>> team.
>
> I think, the patch set should have no API/AB
25 matches
Mail list logo
