Pre-processor magic or test library?

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Nov 2 13:22:31 UTC 2017


On 02/11/17 13:01, Sebastian Huber wrote:
> On 30/10/17 21:56, Chris Johns wrote:
>> On 31/10/2017 01:21, Joel Sherrill wrote:
>>> On Oct 30, 2017 8:43 AM, "Chris Johns" <chrisj at rtems.org
>>> <mailto:chrisj at rtems.org>> wrote:
>>>      On 28/10/2017 22:42, Sebastian Huber wrote:
>>>      > we have currently some pre-processor magic to map the 
>>> standard output
>>>      functions to the RTEMS test printer. This works only if you 
>>> include
>>>      <tmacros.h> in every test file in the right spot. An 
>>> alternative would be to
>>>      use a separate library for all tests, e.g. librtemstest.a which 
>>> provides
>>>      puts(), printf(), fprintf(), etc. How do you think about this?
>>>
>>>      I like it.
>>>
>>> I like the idea but not using the same names for the.methods. this 
>>> will mean
>>> that if the linker magic isn't right, you end up getting the wrong 
>>> implementation
>>>
>> The testing output routings could postfix a character like '|' to 
>> '\n' and the
>> tester can check the output always have that character in column 1 
>> and flag the
>> test and incorrectly linked if it does not?
>
> Using the wrong output facility is not a catastrophe. Most tests work 
> fine with an interrupt driven console driver. I tried to provide a 
> special console driver using the polled char input/output functions 
> (attached patch), however, most console drivers define 
> console_initialize() and the BSP_output_char in one file. Changing 
> this would require more work than I can dedicate to this task.

The pre-processor magic in the testsuite doesn't catch the various 
places in RTEMS which directly use fprintf(), etc. for example 
rtems_capture_print_timestamp().

A quick hack to enable a console driver in librtemsio.a would be to 
define console_*() as weak functions in the normal console driver. 
Separating the console driver from the device-specifics would be several 
days of work. I guess nobody has a time budget for this.

Is this stuff really important for the next RTEMS release?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the devel mailing list