Changes between Version 14 and Version 15 of GSoC/2013/UnifiedAPIs


Ignore:
Timestamp:
12/02/14 10:43:03 (9 years ago)
Author:
Chris Johns
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2013/UnifiedAPIs

    v14 v15  
    3030Based on the observations from lpc24xx, a list of critical files & methods that every BSP must include and use was compiled. These files & methods belonging to a component for a BSP can be deemed as critical or non-critical. The rule-checking is accomplished by the following way :
    3131
    32 #Check if a file is being compiled by searching it's name in the Makefile.am for a BSP.
    33 #If file not found, then report it.
    34 #Check if the file being compiled is present in the correct directory as defined by the rules.
    35 #If location of file is not correct, report it.
    36 #Check if the corresponding functions for a file are defined in there or not. This takes place by searching for the definition of a method in that file with the help of a simple regex [a-z|A-Z|0-9|_]+[ ]*$i[ ]*\(
    37 #If the function is not located in it's specified file, then search whether it's defined in some other file maybe. Report it
    38 #Check whether a required header is being installed by searching it's name in the Makefile.am
    39 #Compile a list of all RTEMS internal functions(i.e starting with an '_' ) defined in cpukit & libcpu.
    40 #Compile another list of functions starting with an '_' being executed in BSP by searching for a ';' to ensure that function is actually being called. Searching for a function being called from a file can be a bit intimidating if the function calling spans multiple lines, meaning that the function name is on one line & the semicolon on another. Since grep only parses line by line, so it cannot do this task very easily. What happens now is that all the newlines are trimmed while searching a file. The whole file now being concatenated in a single line, so grep is ideal for searching the pattern [ |^][_]+[a-z|A-Z|0-9|_]*[ ]*[\n]*\([^;]*\)[ ]*;
    41 #Find common function names in the above two lists in order to ensure that the function being called in a bsp is infact been defined in cpukit or libcpu. Report it.
     321. Check if a file is being compiled by searching it's name in the Makefile.am for a BSP.
     331. If file not found, then report it.
     341. Check if the file being compiled is present in the correct directory as defined by the rules.
     351. If location of file is not correct, report it.
     361. Check if the corresponding functions for a file are defined in there or not. This takes place by searching for the definition of a method in that file with the help of a simple regex [a-z|A-Z|0-9|_]+[ ]*$i[ ]*\(
     371. If the function is not located in it's specified file, then search whether it's defined in some other file maybe. Report it
     381. Check whether a required header is being installed by searching it's name in the Makefile.am
     391. Compile a list of all RTEMS internal functions(i.e starting with an '_' ) defined in cpukit & libcpu.
     401. Compile another list of functions starting with an '_' being executed in BSP by searching for a ';' to ensure that function is actually being called. Searching for a function being called from a file can be a bit intimidating if the function calling spans multiple lines, meaning that the function name is on one line & the semicolon on another. Since grep only parses line by line, so it cannot do this task very easily. What happens now is that all the newlines are trimmed while searching a file. The whole file now being concatenated in a single line, so grep is ideal for searching the pattern [ |^][_]+[a-z|A-Z|0-9|_]*[ ]*[\n]*\([^;]*\)[ ]*;
     411. Find common function names in the above two lists in order to ensure that the function being called in a bsp is infact been defined in cpukit or libcpu. Report it.
    4242
    4343