On 2015-03-07 09:44 +0100, Dominik Taborsky wrote: > I am a newbie to RTEMS, but this sounds great. The current layout is > very confusing to newcomers. Kudos to you, Amar! > Please, see my notes further on.
Great to hear input from new users, thank you! > > include locations > > ~~~~~~~~~~~~~~~~~ > > include/rtems/include/ - Private API > > include/rtems/include/rtems/ - Public API > > include/rtems/bsp/include/ - Common BSP files > > include/rtems/bsp/include/<arch> - Architecture specific > > Just one question here: Why have the public API hidden in a subdir of > private APIs? Shouldn't this be the other way around? This has to do with how we have the includes in source. For instance all source will be moved to a full-path style include. eg: #include <rtems/public.h> #include <rtems/bsp/public.h> For private it would simply be: #include <private.h> #include <sys/private.h> Private APIs can include public but not the other way around. Using this method keeps the build easy as all we need is -Iinclude and nothing more to have everything work. When installed only the include/rtems dir is copied. > > rtems/classic [cpukit/rtems] > > Again, I'm a newbie, but what is 'classic' in RTEMS? > The old 'cpukit' sounds like it's a bunch of tools to work with the CPU. > The new 'classic' sounds like it's the good old RTEMS from history. Yes that is exactly what it is. > > - All RTEMS source will use #include <rtems/header.h> for public API > > You actually mean "<rtems/header.h>" and not "<rtems/rtems.h>" or even > just "<rtems.h>"? When you say "RTEMS source" and "public API", do you > mean the RTEMS source code or 3rd party source that builds with RTEMS? Only private APIs will lack the 'rtems/' prefix. Both the RTEMS source, BSP or any 3rd part software can use it. BSPs will only have headers in the public space eg <rtems/...> Amar. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel