On 29/07/2020 06:55, Gedare Bloom wrote:
On Tue, Jul 28, 2020 at 10:49 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de> 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
<https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/schedulersmp.h?id=3a95a07d88a6926bd2f67dc53c977b8dbc828f9c#n127>
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
