<div dir="ltr">Thank you for explaining everything. I did use the wrong terminology and I keep forgetting this stuff again and again :(.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, it is true that percpu.o will link with<br>scheduleredfsmp.o, but that isn't relevant to the question of whether<br>or not the EDF SMP Scheduler uses the types/structs defined in<br>percpu.h. The scheduler can use a forward declaration to let the<br>compiler know that it is using some struct, and at the linking stage<br>the linker will resolve the names of all the symbols that haven't yet<br>been seen in each object code, by checking the other object files<br>being linked against. If any names are missing, you get a linker error<br>(Unable to resolve symbol...).</blockquote><div>This is smart and answers my question. Got it.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Probably this stuff is written up somewhere</blockquote><div>It is <a href="https://rtemswithrichi.wordpress.com/from-c-to-an-executable/">https://rtemswithrichi.wordpress.com/from-c-to-an-executable/</a> :p</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is typically covered in a textbook on computer organization or computer systems courses in<br>typical CS curriculum.</blockquote><div>We read it in our Principles of Programming Language course.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 29, 2020 at 8:59 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jul 29, 2020 at 2:24 AM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
><br>
> Thanks for your help and reviews, I am going to work on all of your suggestions.<br>
><br>
>> The purpose of <rtems/score/schedulerstrongapa.h> is to enable the<br>
>> application to configure this scheduler and nothing more. Please note<br>
>> that <rtems/score/scheduler.h> uses<br>
>> struct Per_CPU_Control  *cpu<br>
>> and NOT<br>
>> Per_CPU_Control  *cpu<br>
>> You can use struct Per_CPU_Control with a forward declaration.<br>
><br>
><br>
> 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?<br>
><br>
<br>
You seem to be confusing some terminology. #include copies the<br>
contents of the included file into the one that is including it, which<br>
gets to 'see' everything in the included file. This happens during the<br>
C Preprocessing step. After that, the compiler generates intermediate<br>
representation from the high-level language, does an optimization<br>
pass, then generates an object code file. This step is called<br>
"compiling." ASM source files get "assembled" to object code by the<br>
assembler. After that, object code files are linked together during<br>
"linking."<br>
<br>
If a C source code file uses a symbol in a different C source code<br>
file, the two should share the same declaration of that symbol.<br>
Usually, this declaration is made in a .h header file to include in<br>
both source files. However, it is not mandatory, since a C source code<br>
file can make a forward declaration of the symbol, just enough so the<br>
compiler knows what the 'type' is of the symbol in order to generate<br>
suitable code to use it. Later on, at the link stage, the symbol will<br>
be made available to all object codes that are linked together.<br>
<br>
In RTEMS, we separately compile all C source code to object files, and<br>
then link them together to form several libraries of object code.<br>
Finally, an application will link to the libraries to produce the<br>
binary program. So, it is true that percpu.o will link with<br>
scheduleredfsmp.o, but that isn't relevant to the question of whether<br>
or not the EDF SMP Scheduler uses the types/structs defined in<br>
percpu.h. The scheduler can use a forward declaration to let the<br>
compiler know that it is using some struct, and at the linking stage<br>
the linker will resolve the names of all the symbols that haven't yet<br>
been seen in each object code, by checking the other object files<br>
being linked against. If any names are missing, you get a linker error<br>
(Unable to resolve symbol...).<br>
<br>
Probably this stuff is written up somewhere. It is typically covered<br>
in a textbook on computer organization or computer systems courses in<br>
typical CS curriculum.<br>
<br>
Gedare<br>
<br>
> On Wed, Jul 29, 2020 at 10:33 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>> On 29/07/2020 06:55, Gedare Bloom wrote:<br>
>><br>
>> > On Tue, Jul 28, 2020 at 10:49 PM Sebastian Huber<br>
>> > <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>> >> On 27/07/2020 09:44, Richi Dubey wrote:<br>
>> >><br>
>> >>>      Which compiler error do you get? Maybe there is a cyclic dependency.<br>
>> >>><br>
>> >>> I assumed that the schedulersmp.h already includes the percpu.h which<br>
>> >>> was not the case. My bad. The error has been removed.<br>
>> >>><br>
>> >>> I assumed this because schedulersmp.h uses<br>
>> >>> <<a href="https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/schedulersmp.h?id=3a95a07d88a6926bd2f67dc53c977b8dbc828f9c#n127" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/schedulersmp.h?id=3a95a07d88a6926bd2f67dc53c977b8dbc828f9c#n127</a>> Per_CPU_Control<br>
>> >>> and does not show any compilation error, so it should have the<br>
>> >>> percpu.h included in one of its included header files right? If it<br>
>> >>> has, why did my schedulerstrongapa.h that had the schedulersmp.h<br>
>> >>> included give the following error:<br>
>> >>><br>
>> >>> /home/richi/quick-start/src/rtems/cpukit/include/rtems/score/schedulerstrongapa.h:102:3:<br>
>> >>> error: unknown type name 'Per_CPU_Control'<br>
>> >>>     Per_CPU_Control cpu;<br>
>> >> We have two kinds of header files in the implementation of RTEMS.<br>
>> >> Firstly, some header files are included in API header files and are thus<br>
>> >> visible to application code. These header files should only define<br>
>> >> things which are strictly necessary for applications. Secondly, some<br>
>> >> header files are only included in implementation source files.<br>
>> >><br>
>> >> The purpose of <rtems/score/schedulerstrongapa.h> is to enable the<br>
>> >> application to configure this scheduler and nothing more. Please note<br>
>> >> that <rtems/score/scheduler.h> uses<br>
>> >><br>
>> >> struct Per_CPU_Control  *cpu<br>
>> >><br>
>> >> and NOT<br>
>> >><br>
>> >> Per_CPU_Control  *cpu<br>
>> >><br>
>> >> You can use struct Per_CPU_Control with a forward declaration. This<br>
>> >> enables the use of this header file without having to include<br>
>> >> <rtems/score/percpu.h>. You should not include <rtems/score/percpu.h> in<br>
>> >> <rtems/score/schedulerstrongapa.h> and remove everything from this file<br>
>> >> which is not necessary to configure the scheduler.<br>
>> >><br>
>> > I provided a (detailed) review on your PR. One of my comments is<br>
>> > related to creating a schedulerstrongapaimpl.h header file. That is<br>
>> > where you should include extra headers, to avoid "leaking" internal<br>
>> > details to the application.<br>
>><br>
>> I will have a look at the pull request.<br>
>><br>
>> One option is not use a header file and place everything into the source<br>
>> file. We need an implementation header file only if some code is shared<br>
>> with other implementation sources. This should not be the case for this<br>
>> scheduler implementation.<br>
>><br>
</blockquote></div>