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 <ged...@rtems.org> wrote: > On Wed, Jul 29, 2020 at 2:24 AM Richi Dubey <richidu...@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.hu...@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.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
