Strong APA Scheduler : First Draft

[Gedare Bloom]

On Wed, Jul 29, 2020 at 2:24 AM Richi Dubey <richidubey at gmail.com> wrote:
>
> Thanks for your help and reviews, I am going to work on all of your suggestions.
>
>> 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.
>
>
> I understand. I can see that the scheduleredfsmp.c also does not include percpu.h, so the percpu.o is being linked with edf smp scheduler at the time of compilation, right?
>

You seem to be confusing some terminology. #include copies the
contents of the included file into the one that is including it, which
gets to 'see' everything in the included file. This happens during the
C Preprocessing step. After that, the compiler generates intermediate
representation from the high-level language, does an optimization
pass, then generates an object code file. This step is called
"compiling." ASM source files get "assembled" to object code by the
assembler. After that, object code files are linked together during
"linking."

If a C source code file uses a symbol in a different C source code
file, the two should share the same declaration of that symbol.
Usually, this declaration is made in a .h header file to include in
both source files. However, it is not mandatory, since a C source code
file can make a forward declaration of the symbol, just enough so the
compiler knows what the 'type' is of the symbol in order to generate
suitable code to use it. Later on, at the link stage, the symbol will
be made available to all object codes that are linked together.

In RTEMS, we separately compile all C source code to object files, and
then link them together to form several libraries of object code.
Finally, an application will link to the libraries to produce the
binary program. So, it is true that percpu.o will link with
scheduleredfsmp.o, but that isn't relevant to the question of whether
or not the EDF SMP Scheduler uses the types/structs defined in
percpu.h. The scheduler can use a forward declaration to let the
compiler know that it is using some struct, and at the linking stage
the linker will resolve the names of all the symbols that haven't yet
been seen in each object code, by checking the other object files
being linked against. If any names are missing, you get a linker error
(Unable to resolve symbol...).

Probably this stuff is written up somewhere. It is typically covered
in a textbook on computer organization or computer systems courses in
typical CS curriculum.

Gedare

> On Wed, Jul 29, 2020 at 10:33 AM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 29/07/2020 06:55, Gedare Bloom wrote:
>>
>> > On Tue, Jul 28, 2020 at 10:49 PM Sebastian Huber
>> > <sebastian.huber at 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.
>>