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
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/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 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 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 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
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
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
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 +
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
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
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 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:
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 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 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 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:
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
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
---
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
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
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.
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 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
25 matches
Mail list logo
