[GSoC2014] arinc653 on rtems (using pok) patches

[Janek van Oirschot]

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

>
> 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,
Janek