[rtems commit] cpukit, testsuite: Add rtems_printf and rtems_printer support.

Chris Johns chrisj at rtems.org
Wed Jun 1 05:52:23 UTC 2016


On 01/06/2016 15:39, Sebastian Huber wrote:
>>
>> Sorry about this, it looks like my --enable-network build is not
>> working. I will take a look.
>
> Maybe an --enable-networking typo?
>

I have thrown those scripts away and I am adding a tool to the RTEMS 
tools project to do this. I have something going and it is giving me a 
nice set of top warnings. Building 10 option variations for arm, i386, 
powerpc and sparc I am seeing:

Profile Warnings:
     56 cpukit/libmisc/shell/hexdump-odsyntax.c:373:2
     50 cpukit/librpc/src/rpc/get_myaddress.c:130:5
     48 testsuites/psxtests/psxfatal_support/init.c:54:33
     48 testsuites/psxtests/psxfatal_support/init.c:49:46
     48 testsuites/psxtests/psxfatal_support/init.c:54:24
     27 testsuites/sptests/sppagesize/init.c:30:23
     27 testsuites/sptests/sppagesize/init.c:30:5
     25 cpukit/librpc/src/rpc/svc_auth_unix.c:59:1
     25 cpukit/librpc/src/rpc/get_myaddress.c:80:1
     25 cpukit/libnetworking/libc/gethostnamadr.c:164:5
     25 cpukit/libnetworking/libc/res_update.c:90:12
     25 cpukit/libnetworking/libc/gethostnamadr.c:168:4
     25 cpukit/posix/src/pthreadsetschedparam.c:115:7

>>
>>> Why is it defined multiple times in the individual tests and not in
>>> libmisc?
>>
>> I could have gone one of two ways and decided to be specific for now.
>> I did not want to add a new global to all tests yet and create a
>> further variation on how to print in the tests. I wanted to narrow the
>> focus and limit the options so we have a chance at cleaning this stuff
>> up.
>
> The testbeginend.c in libmisc.c needs this variable, so I would rather
> define it here and not in this and that test.
>

Yes that would be nice however the default drops the output without code 
in Init or somewhere to set it up. This way you get an error and that is 
the trigger to make sure it is initialised. No doubt it could all be 
done better.

>>
>> The testsuite is not great in this area and that is being polite. The
>> tmacros.h defines to replace printf, puts etc is not great and prone
>> to errors. The test code does not have a single approach to printed
>> output, you could use a define and include tmacros.h, or use
>> *_begink/*_endk and then implicitly manage the calls to printk, and/or
>> a combination of these. I am not sure if a single approach can be used
>> for all tests or if it matters. I did not have time to review the
>> tests and see what could be done.
>>
>> I see a second bigger pass over the code to remove the support from
>> tmacros.h and add it to libmisc and to change all prints, where ever
>> possible to rtems_printf, and rtems_puts (which will need to be
>> added). There could even be a test version of these added which uses
>> the rtems_printer. Each test will need a printer defined in Init and
>> the output path defined.
>
> We should first open a ticket and gather all requirements, before we
> start to work on this. It will be very labour intensive to add a proper
> test infrastructure to our existing test suite. The test suite itself is
> great, but it is more or less unstructured.
>

Which is bigger, the task I describe or getting a suitable and workable 
set of requirements everyone agrees on? ;)

Chris



More information about the devel mailing list