[GSoC2014] arinc653 on rtems (using pok) patches

[Joel Sherrill]

On 8/19/2014 4:34 PM, Janek van Oirschot wrote:
> 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.
When you rebase, you get the list of patches. format-patch will generate
a file for
each of them. Just use git send-email for the ones you want reviewed and
merged first.
When you rebase, they should magically be eliminated.

Worst case, you make a new branch from master and apply the remaining ones.
>> 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.
Please report this. This sounds like an independent issue which needs to
be run down.
>> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985