[GSoC2014] arinc653 on rtems (using pok) patches

Janek van Oirschot janekvoirschot at gmail.com
Tue Aug 19 21:34:10 UTC 2014

On Mon, Aug 18, 2014 at 3:13 PM, Gedare Bloom <gedare at rtems.org> wrote:
> If you're using git for your development, you can use 'git
> format-patch' to convert a set of commits into a set of patches. Some
> properly formatted git patches can make it easier to review and merge
> your code. Some other notes follow.

Yeah, I knew git is able to generate patches but I was worried that it
would also take the virtualpok bsp and paravirt patches along with my

> virtualpok_arinc653.patch:
> * it seems the only part of this patch specific to the arinc653 code
> is the Makefile.am and preinstall.am changes?
It seems so, I did include some small edits and adjustments I needed
to apply to get my RTEMS on POK enviroment running.

> * The virtualizationlayercpu.h is missing. Is this supposed to come
> from another patch already?
Yeah, I thought it was included by one of the earlier virtualpok BSP
patches. It's simply the virtualizationlayercpu.h located in
$POK/examples/rtems-guest/ but can be added to my patch.

> * You comment out a few lines in bspstart.c, are these things that were broken?
Not so much broken but in my case the rtems on pok enviroment broke
after a git pull so it got recommended to me at some point to disable
those as I don't need them for my application.

> * Is the linkcmds change required for running pok-rtems?
For me, it was required. The old linkcmd script was causing undefined
TLS errors while building RTEMS.

> hello_init_c.patch:
> * This would be much improved if you provided a new example instead of
> replacing the existing one, like 'arinc653_test.c' or similar.
No problem, was working with the default hello world because the setup
for working with hello world was already there. Now that I know this
method works to get arinc653 calls working a new and separate example
program for arinc653 is the next step and definitely on my TODO list.

> libpok_rtems_arinc653.patch:
> It seems incorrect to remove extern from all of these arrays. Usually
> for global variables in C code, there should be one declaration of the
> variable with the 'extern' attribute in a header file that gets
> included in every c source file that needs that variable, and then one
> definition of the variable without 'extern' in just one of the .c
> files. Please explain your changes.
The 'extern' variables would cause compilation errors. I also couldn't
find any definition of those arrays without the 'extern'. I
temporarily removed them and since I only tested CREATE_* of each
arinc653 subset so since the scope was one source file this wasn't a
problem. After some debugging of e.g. CREATE_BLACKBOARD and it works
without returning an error a better structure for all 'extern'
variables in combination with rtems will be implemented as then they
then need to be global.

Thanks for the feedback,

More information about the devel mailing list