Sebastien Dugue wrote:
> Hi all,
>
> On Thu, 16 Oct 2008 11:51:03 -0700 Darren Hart <[EMAIL PROTECTED]> wrote:
>
>> Gilles Carry wrote:
>>> From: gilles.carry <[EMAIL PROTECTED]>
>>>
>> Hi Gilles,
>>
>>> This patch is to allow user to have results and statistics dumped
>>> as XML files.
>>> This patch does not alter the LTP/RT traditional data dump.
>>> A new global command line option is used: -x <id>
>>> Using this option makes results to be dumped as XML files if the test
>>> implements it.
>>> Combining '-s -x' dumps stats both in traditionnal format and XML format
>>> (into separate files).
>>> The main goal here is to have the ability to store and compare results
>>> and stats of testruns for different configurations and architectures.
>>> The XML files created, not only store stats data but also system information
>>> and timestamps, useful to identify how the test was run.
>>> The choice of XML allows future format modifications while still being
>>> able to compare old and new dumps.
>> So certainly no objection to improving the flexibility of the data
>> logging. However, here are a couple of points I think we should
>> consider prior to incorporating the xml changes:
>>
>> o We should consider the LTP as a whole and see if there is some
>> possibilty of an integrated output format.
>> o If we add XML logging support I feel it should be self contained (not
>> added in to libstats.
>> o The test writer should not be required to explicitly print xml tags,
>> I'd expact such a logger to be used something more like this:
>>
>> xml_element *xe = xml_log_init("matrix_mult")
>> xml_element *se = xml_log_new_element(xe, "sequential")
>> xml_log_add_stats(se, seq_dat) /* seq_dat is a stats_container_t * */
>> xml_log_end_element(se)
>> xml_element *ce = xml_log_new_element(xe, "concurrent")
>> xml_log_add_stats(ce, con_dat)
>> xml_log_close(xe)
>>
>> This will enable the xml lib to handle things like indentation, proper
>> quoting of the CDATA elements, proper newlines (which should probably
>> \r\n as these may be read/processed on non UNIX platforms, etc. And if
>> we're going to go to this extreme, we would probably be best served by
>> using an existing XML library. I've used the python framework, I
>> suspect there is something similar for C. The build should be able to
>> detect the availability of this lib and then build with xml or without
>> accordingly.
>>
>> --
>> Darren
>
> While I'm not really fond of this xml thing (and all those meta languages as
> well) wouldn't it be possible to do this in a post processing phase from the
> raw stats data we already have.
>
> That way we would not need any extra stuff running on the test box. I'm
> particularly thinking of embedded hardware here, yes I know memory is getting
> bigger by the day, but still I would rather do the minimum on the hardware we
> want to test and defer post processing to more capable HW via scripts.
>
> I may be working on big SMP boxes, but the embedded stuff is never far
> away in my thoughts.
>
> Sebastien.
>
I agree. I'd very much like to see this done in post processing. In
fact, perhas the plt generation should also be post processed via a
python script. I recently spent some considerable time massaging the
dat and plt files to generate plots I could share at the Linux
Foundation End User Summit. If this was in a post processing script,
much of what I had to do would already be handled in the script.
However, if the xml output is from a system library and is a build
option (which defaults to off) it wouldn't effect the embedded folks or
the xml-haters :-) Still, I think post-processing makes the most sense
to me.
-
Darren.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
