Strong APA Scheduler : First Draft

Sebastian Huber sebastian.huber at
Wed Jul 29 05:03:12 UTC 2020

On 29/07/2020 06:55, Gedare Bloom wrote:

> On Tue, Jul 28, 2020 at 10:49 PM Sebastian Huber
> <sebastian.huber at> wrote:
>> On 27/07/2020 09:44, Richi Dubey wrote:
>>>      Which compiler error do you get? Maybe there is a cyclic dependency.
>>> I assumed that the schedulersmp.h already includes the percpu.h which
>>> was not the case. My bad. The error has been removed.
>>> I assumed this because schedulersmp.h uses
>>> <> Per_CPU_Control
>>> and does not show any compilation error, so it should have the
>>> percpu.h included in one of its included header files right? If it
>>> has, why did my schedulerstrongapa.h that had the schedulersmp.h
>>> included give the following error:
>>> /home/richi/quick-start/src/rtems/cpukit/include/rtems/score/schedulerstrongapa.h:102:3:
>>> error: unknown type name 'Per_CPU_Control'
>>>     Per_CPU_Control cpu;
>> We have two kinds of header files in the implementation of RTEMS.
>> Firstly, some header files are included in API header files and are thus
>> visible to application code. These header files should only define
>> things which are strictly necessary for applications. Secondly, some
>> header files are only included in implementation source files.
>> The purpose of <rtems/score/schedulerstrongapa.h> is to enable the
>> application to configure this scheduler and nothing more. Please note
>> that <rtems/score/scheduler.h> uses
>> struct Per_CPU_Control  *cpu
>> and NOT
>> Per_CPU_Control  *cpu
>> You can use struct Per_CPU_Control with a forward declaration. This
>> enables the use of this header file without having to include
>> <rtems/score/percpu.h>. You should not include <rtems/score/percpu.h> in
>> <rtems/score/schedulerstrongapa.h> and remove everything from this file
>> which is not necessary to configure the scheduler.
> I provided a (detailed) review on your PR. One of my comments is
> related to creating a schedulerstrongapaimpl.h header file. That is
> where you should include extra headers, to avoid "leaking" internal
> details to the application.

I will have a look at the pull request.

One option is not use a header file and place everything into the source 
file. We need an implementation header file only if some code is shared 
with other implementation sources. This should not be the case for this 
scheduler implementation.

More information about the devel mailing list