On 8/19/2014 4:34 PM, Janek van Oirschot wrote: > 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. 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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel