change log for rtems (2010-06-22)

Joel Sherrill joel.sherrill at OARcorp.com
Wed Jun 23 14:57:12 UTC 2010


On 06/23/2010 07:23 AM, Sebastian Huber wrote:
> On 06/23/2010 02:16 PM, Joel Sherrill wrote:
>    
>> On 06/22/2010 08:49 PM, Chris Johns wrote:
>>      
>>> On 23/06/10 6:12 AM, rtems-vc at rtems.org wrote:
>>>
>>>        
>>>> diff -u rtems/cpukit/libcsupport/include/rtems/libio_.h:1.37
>>>> rtems/cpukit/libcsupport/include/rtems/libio_.h:1.38
>>>> --- rtems/cpukit/libcsupport/include/rtems/libio_.h:1.37    Mon Jun
>>>> 14 08:35:45 2010
>>>> +++ rtems/cpukit/libcsupport/include/rtems/libio_.h    Tue Jun 22
>>>> 15:03:41 2010
>>>> @@ -148,13 +148,7 @@
>>>>      *  Macro to free a node.
>>>>      */
>>>>
>>>> -#define rtems_filesystem_freenode( _node ) \
>>>> -  do { \
>>>> -    if ( (_node)->ops )\
>>>> -      if ( (_node)->ops->freenod_h ) \
>>>> -        (*(_node)->ops->freenod_h)( (_node) ); \
>>>> -  } while (0)
>>>> -
>>>> +void rtems_filesystem_freenode( rtems_filesystem_location_info_t*
>>>> node );
>>>>
>>>>
>>>>          
>>> Why has this been done ?
>>>
>>> This code is a hot spot in the file system. Not all file systems need to
>>> free a node but they now suffer an extra call. Maybe the overhead is not
>>> too much but it does add up.
>>>
>>>
>>>        
>> It lead to horrible branch patch explosion and code size.   It introduced
>> a lot of paths that had to tested.  Look at the top two entries here:
>>
>> http://www.rtems.org/ftp/pub/rtems/people/joel/coverage/erc32.html#OsPD
>>
>> Code coverage went up about 4%!!! And the number of branches which
>> are executed but we have only taken one direction (e.g. always taken
>> or never taken) dropped from 727 to 626.
>>      
> We should consider to forbid NULL pointers for ops tables and handlers.
> Instead we should provide reasonable default handlers.  This would eliminate a
> lot of ifs and make the code more readable.
>
>    
I was thinking of the same thing.  There are a LOT of places there
are checks and having standard stubs would really help the code.

As we try to improve testability, this type of thing is a very good
technique.  Plus it also improves readability IMO.

--joel




More information about the vc mailing list