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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
