On Mon, Aug 18, 2014 at 3:13 PM, Gedare Bloom <ged...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
