Subject: BenchMark Apps for RTEMS

[Rempel, Cynthia]

>________________________________________
>From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Gedare Bloom [gedare at rtems.org]
>Sent: Friday, April 19, 2013 7:26 AM
>To: Vivek Krishnamurthy
>Cc: RTEMS Devel
>Subject: Re: Subject: BenchMark Apps for RTEMS
>
>Vivek,
>
>Do feel free to make some notes and perhaps even some blog articles
>about what you learn. Often the knowledge you get from fresh eyes is
>really helpful for improving the community's knowledge base.
Yes, your experiences with the development process will be very helpful.

>
>I think that it is trivial to port benchmarks (and applications) that
>come with a Makefile just by updating the Makefiles. It is something
>that, once you get the hang of it, can be done in a couple of hours.
This is very true, once you get the hang of it, using Makefile inclusions makes this task trivial...
More complicated build systems, using Makefile.in, often require special configurations, see rtems-addon-packages...

>However, the process of integrating multiple benchmarks/applications
>into a kit, making them easy to build/run,
This can be accomplished with configurations and build-sets in RTEMS Source Builder (RSB), the challenge would be to generate the RSB config, and RSB build set files. http://git.rtems.org/chrisj/rtems-source-builder.git/

>and able to re-update each
>ported benchmark/application when the upstream changes, are all
>important considerations for the design.
This is not already addressed in RTEMS Source Builder (RSB)...
Patches should be upstreamed as much as possible though.

>
>A "kit" needs to be more than just a collection of one-time ports of
>applications to work with RTEMS. It should be a way to easily update
>to new versions and to compile into user applications seamlessly. 
This is very true

>I
>think that a smarter framework than Makefiles can be used to support
>things like maintaining patches against the upstream sources and
>compiling kit code into something usable by applications like a
>library. This library notion may be less useful for the benchmark
>code, although in some ways treating each benchmark application as a
>library might make it easy to create a wrapper application that
>executes the benchmark in such a way to minimize the change in the
>benchmark code. Not sure on that front.

Because libraries are relocatable the functions can then be linked into
an rtems executable...
I like to turn applications into libraries, change the function names of main, 
then link them into shell applications...
Eventually, we will want to be able to run the ported application from a
crontab, so we can verify the ported application still run properly.

>
>-Gedare