Strong APA Scheduler : First Draft

[Richi Dubey]

Thank you for explaining everything. I did use the wrong terminology and I
keep forgetting this stuff again and again :(.

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...).

This is smart and answers my question. Got it.

Probably this stuff is written up somewhere

It is https://rtemswithrichi.wordpress.com/from-c-to-an-executable/ :p


> It is typically covered in a textbook on computer organization or computer
> systems courses in
> typical CS curriculum.

We read it in our Principles of Programming Language course.

On Wed, Jul 29, 2020 at 8:59 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200730/4a56a98a/attachment.html>