From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sfi-mx-4.v28.ch3.sourceforge.com ([172.29.28.124] helo=mx.sourceforge.net) by 335xhf1.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1MHa0O-0002eZ-AS for ltp-list@lists.sourceforge.net; Fri, 19 Jun 2009 09:03:28 +0000 Received: from eu1sys200aog110.obsmtp.com ([207.126.144.129]) by 1b2kzd1.ch3.sourceforge.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69) id 1MHa0K-0001nY-CB for ltp-list@lists.sourceforge.net; Fri, 19 Jun 2009 09:03:28 +0000 Message-ID: <4A3B542E.708@st.com> Date: Fri, 19 Jun 2009 11:02:38 +0200 From: Francesco RUNDO MIME-Version: 1.0 References: <4A3A049B.2000002@st.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------010701070805080003070103" Subject: Re: [LTP] [FIX HTML PATCH] ltp-genhtml List-Id: Linux Test Project General Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltp-list-bounces@lists.sourceforge.net To: naresh kamboju Cc: ltp-list@lists.sourceforge.net, maxin john , brinda_mn@yahoo.co.in, Manas Kumar Nayak , Oleg Nesterov , rohit.170309@gmail.com This is a multi-part message in MIME format. --------------010701070805080003070103 Content-Type: multipart/alternative; boundary="------------090709020102090803050407" --------------090709020102090803050407 Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable Hi Naresh, thanks for your reply. Below some considerations: naresh kamboju wrote: >Hi Francesco, > > =20 > >>In fact, in case the results of LTP session was related to cross-executio= n, the >infiormation about KERNEL_VERSION and MACHINE_ARCHITECTURE have to = >be referred to the target and not to the host. Do you agree ? >> =20 >> >Yes. >I agree with you. >I have been using LTP for Target Board executions not on Host Machine. >As per my understating KERNEL_VERSION and MACHINE_ARCHITECTURE are >should come from env right? > Yes. >But I could not print these variables in HTML file. > Why not ? By means of (before to run genhtml.pl on the HOST): export KERNEL_VERSION=3D" xxxxxxxxxxxxxxxx" export MACHINE_ARCH=3D" xxxxxxxxxxxxxxxxxxxxx" you will be able to export on the final HTML file the info contained in=20 the above env variables. The attached HTML log shows a typical summary (I report only subset of=20 info related to the env variables). >Please refer the results published in LTP download page for 31-May-2009 re= lease. >http://sourceforge.net/project/platformdownload.php?group_id=3D3382 > > >LTP Results: > >ltp-full-20090531_results_kernel-2.6.18-128.el5_architecture-ppc64.tgz >ltp-full-20090531_results_kernel-2.6.18-128.el5_architecture-x86_64.tgz >ltp-full-20090531_results_kernel-2.6.18-128.el5PAE_architecture-i386.tgz >ltp-full-20090531_results_kernel-2.6.23.13_architecture-ia64.tgz >ltp-full-20090531_results_kernel-2.6.27.19-5-default_architecture-i386.tgz > >None of the above results got printed these two KERNEL_VERSION and >MACHINE_ARCHITECTURE variables in HTML. > Probably because they haven't been defined the env variables. > > > =20 > >>With your fix, by using "uname -r" and "uname -m", to avoid to report wro= ng >information, you have to run the "genhtml.pl" script over the target sy= stem because if >you run the genhtml.pl on the host, you will get wrong inf= ormation about the kernel >version and machine architecture. >> =20 >> >No. >As per my understanding to make generic script =93uname -r" and "uname >-m" are best way of use. All the target Machines are wont have full >=93env=94 support to extract KERNEL_VERSION and MACHINE_ARCHITECTURE info. >Ofcourse my target Machine can not extract these variables. > No env variables have to be processed in the target. The env variables=20 will be used on the HOST execution of genthml.pl. > >"uname -r" and "uname -m" are from target not from Host I guess. >Because runltp script will runs on target so obviously genhtml.pl will >run when =96g option is specified. =93 #sh runltp =96g >ltp-full-results-file.html=94 > =20 > >>Moreover, the assumption to run genhtml.pl over the target is not safe as= often the target >systems are embedded systems which do not support PERL. >> =20 >> > >Yes. That is true. >When we run runltp with =96g option to create HTML file the person using >this option should have knowledge that this script will use PERL >script if there is no PERL no HTML file will generate right? > =20 > No, with the usage of env variables on the "genhtml.pl", you can have=20 HTML file even though PERL is not supported on your target. This is an=20 advantage! Moreover, you can manage and process "off-line" LTP report without=20 having the risk to add in the report HOST information instead of TARGET=20 ones. > =20 > >>With the fix I've proposed and accepted, the LTP-user by means of the sim= ple env >variables, can define the right information to be reported on the = LTP results table about >kernel version and machine architecture. >> =20 >> >I have attached my HTML output file after and before patch. >Please share your commands for ltp executions and results HTML file >and other files. >Before and after your patch. > The steps I follow are simply: 1) runltp >> LTP.log (run on the TARGET platform); 2) export KERNEL_VERSION=3D" xxxxxxxxxxxxxxxx" export MACHINE_ARCH=3D" xxxxxxxxxxxxxxxxxxxxx" ...................... (run on the HOST platform) 3) genhtml.pl LTP.log LTP.html (run on the HOST platform); In this way I avoid to make assumptions about TARGET requirements (PERL,=20 HTML, etc...). The piece of attached LTP-log.html shows what I got. I confirm my opinion to keep the current policy to generate HTML summary=20 info. Best Regards, FR --------------090709020102090803050407 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hi Naresh,

thanks for your reply. Below some considerations:

naresh kamboju wrote:
Hi Francesco,

  
In fact, in case the results of LTP session was related =
to cross-execution, the >infiormation about KERNEL_VERSION and MACHINE_A=
RCHITECTURE have to >be referred to the target and not to the host. Do y=
ou agree ?
    
Yes.
I agree with you.
I have been using LTP for Target Board executions not on Host Machine.
As per my understating KERNEL_VERSION and MACHINE_ARCHITECTURE are
should come from env right?
Yes.


But I could not print these variables in HTML file.

Why not ?
By means of (before to run genhtml.pl on the HOST):
export KERNEL_VERSION=3D" xxxxxxxxxxxxxxxx"
export MACHINE_ARCH=3D" xxxxxxxxxxxxxxxxxxxxx"
you will be able to export on the final HTML file the info contained in the above env variables.
The attached HTML log shows a typical summary (I report only subset of info related to the env variables).

Please refer the results published in LTP download page for 31-May-2009 rel=
ease.
http://sourceforge.net/project/platfor=
mdownload.php?group_id=3D3382


LTP Results:

ltp-full-20090531_results_kernel-2.6.18-128.el5_architecture-ppc64.tgz
ltp-full-20090531_results_kernel-2.6.18-128.el5_architecture-x86_64.tgz
ltp-full-20090531_results_kernel-2.6.18-128.el5PAE_architecture-i386.tgz
ltp-full-20090531_results_kernel-2.6.23.13_architecture-ia64.tgz
ltp-full-20090531_results_kernel-2.6.27.19-5-default_architecture-i386.tgz

None of the above results got printed these two KERNEL_VERSION and
MACHINE_ARCHITECTURE variables in HTML.

Probably because they haven't been defined the env variables.


  
With your fix, by using "uname -r" and "uname -m", to av=
oid to report wrong >information, you have to run the "genhtml.pl" scrip=
t over the target system because if >you run the genhtml.pl on the host,=
 you will get wrong information about the kernel >version and machine ar=
chitecture.
    
No.
As per my understanding to make generic script =93uname -r" and "uname
-m" are best way of use. All the target Machines are wont have full
=93env=94 support to extract KERNEL_VERSION and MACHINE_ARCHITECTURE info.
Ofcourse my target Machine can not extract these variables.

No env variables have to be processed in the target. The env variables will be used on the HOST execution of genthml.pl.


"uname -r" and "uname -m" are from target not from Host I guess.
Because runltp script will runs on target so obviously genhtml.pl will
run when =96g option is  specified. =93 #sh runltp =96g
ltp-full-results-file.html=94
  
Moreover, the assumption to run genhtml.pl over the targ=
et is not safe as often the target >systems are embedded systems which d=
o not support PERL.
    

Yes. That is true.
When we run runltp with =96g option to create HTML file the person using
this option should have knowledge that this script will use PERL
script if there is no PERL no HTML file will generate right?

No, with the usage of env variables on the "genhtml.pl", you can have HTML file even though PERL is not supported on your target. This is an advantage!

Moreover, you can manage and process "off-line" LTP report without having the risk to add in the report HOST information instead of TARGET ones.

  
With the fix I've proposed and accepted, the LTP-user by=
 means of the simple env >variables, can define the right information to=
 be reported on the LTP results table about >kernel version and machine =
architecture.
    
I have attached my HTML output file after and befor=
e patch.
Please share your commands for ltp executions and results HTML file
and other files.
Before and after your patch.
The steps I follow are simply:

1) runltp >> LTP.log (run on the TARGET platform);

2)=A0 export KERNEL_VERSION=3D" xxxxxxxxxxxxxxxx"
=A0=A0=A0=A0 export MACHINE_ARCH=3D" xxxxxxxxxxxxxxxxxxxxx"
=A0 =A0=A0 ...................... (run on the HOST platform)

3) genhtml.pl LTP.log LTP.html (run on the HOST platform);

In this way I avoid to make assumptions about TARGET requirements (PERL, HTML, etc...).

The piece of attached LTP-log.html shows what I got.

I confirm my opinion to keep the current policy to generate HTML summary info.

Best Regards,
FR


--------------090709020102090803050407-- --------------010701070805080003070103 Content-Type: text/html; name="LTP-log.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="LTP-log.html"

Summary Report


  • Click Here for Detailed Report

    • Test Summary

    		Pan reported all Test Pass

    LTP Version ltp-full-20090430
    Start Time Fri May 22, 2009 - 2.44 pm
    End Time Fri May 22, 2009 - 2.44 pm
    Log Result http://www.stlinux.com/drupal/
    Output/Failed Result http://www.stlinux.com/drupal/
    Total Tests
    Total Test TPASS:
    Total Test TFAIL:
    Total Test TBROK
    Total Test TWARN
    Total Test TRETR
    Total Test TCONF 7
    Kernel Version linux-sh4-2.6.23_stm23_120
    Machine Architecture SuperH(SH) - STBi7100c3 reference board -mb442-
    Hostname STSLX02
    --------------010701070805080003070103 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects --------------010701070805080003070103 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list --------------010701070805080003070103--