Re: [PATCH v2] Comment added

[Sebastian Huber]

On 16/06/2019 20:13, Ravindra Meena wrote:

---
  misc/CTF/record-ctf.ref | 55 +
  1 file changed, 37 insertions(+), 18 deletions(-)

diff --git a/misc/CTF/record-ctf.ref b/misc/CTF/record-ctf.ref
index a27757c..bdb9648 100644
--- a/misc/CTF/record-ctf.ref
+++ b/misc/CTF/record-ctf.ref

[...]

  clock {
-name = ctf_clock;
-freq = 1000;
-offset_s = 1421703448;
+name = ctf_clock; /* name of montonic clock */
+freq = 1000; /* frequency, in HZ */


Why 1000Hz?


+offset_s = 1421703448;


What is this for an offset?


  };
  
+/*

+ *  A reference to the clock added within an integer type
+ */
+
  typealias integer {
  size = 64;
  map = clock.ctf_clock.value;
  } := ctf_clock_int_t;


Why does this start with "ctf_"?

  
+/*

+ * Trace stream packet having header and context.
+ *
+ * @param event.header includes id(unique identifier of stream) and timestamp.
+ * @param packet.context includes clock timestamp, cpu id, event and event 
data.
+ */
+
  stream {
  id = 0;
+event.header := struct {
+uint32_t id;


What is this for an id?


+ctf_clock_int_t timestamp;


Timestamp of what?


+};
  packet.context := struct {
ctf_clock_int_t timestamp;
uint32_t cpu;
uint32_t event;
uint64_t data;
  };
-event.header := struct {
-uint32_t id;
-ctf_clock_int_t timestamp;
-};
  };
  
  event {

-id = 0;
-name = "ctf_event";
-stream_id = 0;
+id = 0; /* event id
+name = "ctf_event"; /* event name */
+stream_id = 0; /* signifies stream id which event is supposed to concat 
with events */
  fields := struct {
-uint32_t a;
-uint16_t b;
-string c;
+uint32_t a; /*event 1*/
+uint16_t b; /*event 2*/
+string c; /*event 3*/


What are events 1, 2, 3?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Add Testsuite for PSXINTTYPES01

[Vaibhav Gupta]

Patch v3 is correct? Or i need to do any more changes?

On Fri, Jun 14, 2019, 1:00 AM Vaibhav Gupta 
wrote:

> ---
>  testsuites/psxtests/Makefile.am   |   7 +
>  testsuites/psxtests/configure.ac  |   1 +
>  testsuites/psxtests/psxinttypes01/init.c  | 233 ++
>  .../psxtests/psxinttypes01/psxinttypes01.doc  |  43 
>  .../psxtests/psxinttypes01/psxinttypes01.scn  |  44 
>  5 files changed, 328 insertions(+)
>  create mode 100644 testsuites/psxtests/psxinttypes01/init.c
>  create mode 100644 testsuites/psxtests/psxinttypes01/psxinttypes01.doc
>  create mode 100644 testsuites/psxtests/psxinttypes01/psxinttypes01.scn
>
> diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> index 1e354c0df7..59c9f2085b 100755
> --- a/testsuites/psxtests/Makefile.am
> +++ b/testsuites/psxtests/Makefile.am
> @@ -523,6 +523,13 @@ psxintrcritical01_CPPFLAGS = $(AM_CPPFLAGS) \
>  endif
>  endif
>
> +if TEST_psxinttypes01
> +psx_tests += psxinttypes01
> +psxinttypes01_SOURCES = psxinttypes01/init.c
> +psxinttypes01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxinttypes01) \
> +   $(support_includes)
> +endif
> +
>  if HAS_POSIX
>  if TEST_psxitimer
>  psx_tests += psxitimer
> diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> index cdd6ee7e4e..85559e4aa5 100644
> --- a/testsuites/psxtests/configure.ac
> +++ b/testsuites/psxtests/configure.ac
> @@ -91,6 +91,7 @@ RTEMS_TEST_CHECK([psxid01])
>  RTEMS_TEST_CHECK([psximfs01])
>  RTEMS_TEST_CHECK([psximfs02])
>  RTEMS_TEST_CHECK([psxintrcritical01])
> +RTEMS_TEST_CHECK([psxinttypes01])
>  RTEMS_TEST_CHECK([psxitimer])
>  RTEMS_TEST_CHECK([psxkey01])
>  RTEMS_TEST_CHECK([psxkey02])
> diff --git a/testsuites/psxtests/psxinttypes01/init.c
> b/testsuites/psxtests/psxinttypes01/init.c
> new file mode 100644
> index 00..94df8206c0
> --- /dev/null
> +++ b/testsuites/psxtests/psxinttypes01/init.c
> @@ -0,0 +1,233 @@
> +/**
> + *  @file
> + *  @brief Test suite for inttypes.h methods
> + */
> +
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2019, Aditya Upadhyay and Vaibhav Gupta
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +const char rtems_test_name[] = "PSXINTTYPE 01";
> +
> +/* forward declarations to avoid warnings */
> +rtems_task Init(rtems_task_argument ignored);
> +
> +rtems_task Init(rtems_task_argument ignored)
> +{
> +  int   base= 10;
> +  int   invalid_base= 40;
> +
> +  char *nptr1_p = "123abc";
> +  char*nptr1_p_errange = "99";
> +  char *nptr1_n = "-123abc";
> +  char*nptr1_n_errange = "-99";
> +  char *endptr1 = NULL;
> +
> +  wchar_t  *nptr2_p = L"123junk";
> +  wchar_t  *nptr2_p_errange = L"99";
> +  wchar_t  *nptr2_n = L"-123junk";
> +  wchar_t  *nptr2_n_errange = L"-99";
> +  wchar_t  *endptr2 = NULL;
> +
> +  intmax_t  result_strtoimax;
> +  uintmax_t result_strtoumax;
> +
> +  TEST_BEGIN();
> +
> +  /* Test for strtoimax  */
> +  puts( "\nstrtoimax Testcases" );
> +  puts( "Valid Inputs - Positive Number" );
> +  result_strtoimax = strtoimax( nptr1_p, &endptr1, base );
> +  rtems_test_assert( result_strtoimax == 123 );
> +
> +  puts( "Final string pointed by endptr" );
> +  rtems_test_assert( endptr1 == ( nptr1_p + 3 ) );
> +
> +  puts( "Valid Inputs - Negative N

GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

Hi,

Here is the work summary of 13th and 14th June.

*13th June:*
1. I sent a patch for RTEMS trace generation example and made a push on
GitHub forked repository also.
https://github.com/rmeena840/rtems-docs/commit/68e2239548dac48f533572152a5c8033ff2122b6
2. I set up the babeltrace 2.0 master branch as it has the decoder(source
plugin) examples shared by babeltrace community.
https://github.com/efficios/babeltrace

These are the links they shared with me:
[1]
http://git.efficios.com/?p=babeltrace.git;a=tree;f=plugins/text/dmesg;h=a45918aaf266dac29db6f7a0e4d08ffdb056131a
[2]
http://git.efficios.com/?p=babeltrace.git;a=tree;f=plugins/ctf/fs-sink;h=b96b435706cac0ed50cb64918603172b67afc424

As babeltrace 2.0 master branch is under progress. They have not updated
their documentation. I was not able to run the examples. I raised a query
asking how I can use the examples? I haven't received a reply yet.

*14th June:*
I tried to write TSDL description by following https://diamon.org/ctf/.
Here is the patch I sent
https://lists.rtems.org/pipermail/devel/2019-June/026166.html
I explored the examples/blogs shared by Sebastian.
https://lttng.org/blog/2014/11/25/tracing-bare-metal-systems/

I explored the metadata file of Trace Compass examples
https://github.com/tuxology/tracevizlab
This metadata is quite similar to metadata I wrote
https://lists.rtems.org/pipermail/devel/2019-June/026166.html

*Plan for the week:*
I will improve the metadata I wrote.
https://lists.rtems.org/pipermail/devel/2019-June/026166.html
I will explore bartectf tracing example
https://github.com/efficios/epiphany-examples/tree/barectf-tracing/apps/barectf-tracing
This example is similar to the objective of this GSoC project. The targets
generates CTF data and send it back to the host.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Comment added

[Ravindra Kumar Meena]

On Mon, Jun 17, 2019 at 1:45 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/06/2019 20:13, Ravindra Meena wrote:
> > ---
> >   misc/CTF/record-ctf.ref | 55
> +
> >   1 file changed, 37 insertions(+), 18 deletions(-)
> >
> > diff --git a/misc/CTF/record-ctf.ref b/misc/CTF/record-ctf.ref
> > index a27757c..bdb9648 100644
> > --- a/misc/CTF/record-ctf.ref
> > +++ b/misc/CTF/record-ctf.ref
> [...]
> >   clock {
> > -name = ctf_clock;
> > -freq = 1000;
> > -offset_s = 1421703448;
> > +name = ctf_clock; /* name of montonic clock */
> > +freq = 1000; /* frequency, in HZ */
>
> Why 1000Hz?
>
The freq field is the initial frequency of the clock, in Hz. If the freq
field is not present, the frequency is assumed to be 10 (providing
clock increment of 1 ns). I set to 1000HZ just for getting started.

>
> > +offset_s = 1421703448;
>
> What is this for an offset?
>
This offset is a difference between the beginning of clock and the actual
start of the clock. The event will be recorded just after the offset.

>
> >   };
> >
> > +/*
> > + *  A reference to the clock added within an integer type
> > + */
> > +
> >   typealias integer {
> >   size = 64;
> >   map = clock.ctf_clock.value;
> >   } := ctf_clock_int_t;
>
> Why does this start with "ctf_"?
>
ctf_clock is the name of clock struct I created just above this. It is a
reference to the clock name.

>
> >
> > +/*
> > + * Trace stream packet having header and context.
> > + *
> > + * @param event.header includes id(unique identifier of stream) and
> timestamp.
> > + * @param packet.context includes clock timestamp, cpu id, event and
> event data.
> > + */
> > +
> >   stream {
> >   id = 0;
> > +event.header := struct {
> > +uint32_t id;
>
> What is this for an id?
>
It is a unique identifier for stream header. There will be many streams so
in order to identify the streams I have set the id here.

>
> > +ctf_clock_int_t timestamp;
>
> Timestamp of what?
>
 It is the timestamp of the stream header. It is different from event
header. The event heder can have a beginning  and ending timestamp.

>
> > +};
> >   packet.context := struct {
> >   ctf_clock_int_t timestamp;
> >   uint32_t cpu;
> >   uint32_t event;
> >   uint64_t data;
> >   };
> > -event.header := struct {
> > -uint32_t id;
> > -ctf_clock_int_t timestamp;
> > -};
> >   };
> >
> >   event {
> > -id = 0;
> > -name = "ctf_event";
> > -stream_id = 0;
> > +id = 0; /* event id
> > +name = "ctf_event"; /* event name */
> > +stream_id = 0; /* signifies stream id which event is supposed to
> concat with events */
> >   fields := struct {
> > -uint32_t a;
> > -uint16_t b;
> > -string c;
> > +uint32_t a; /*event 1*/
> > +uint16_t b; /*event 2*/
> > +string c; /*event 3*/
>
> What are events 1, 2, 3?
>
I have added this event just for getting started. I thought it would be
better to get it reviewed this much TSDL code.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Comment added

[Ravindra Kumar Meena]

>
> >  misc/CTF/record-ctf.ref | 55
> +
>
> We should avoid uppercase or mix case in file names unless they are
> existing or
> in imported code. We have some hosts that are case insensitive and our
> experience over the years is this can cause problems. :)
>
Okay. I didn't know that. :)

>
> Is this file for the rtems-tools repo?

Yes

> If it is not please ignore the following.
>
> I wonder if there should be a top level trace directory to gather all the
> trace
> pieces in one place. I think trace is important enough to have this
> status. So
> this file could be ...
>
>  trace/config/ctf/record-ctf.ref
>
> or
>
>  trace/config/record-ctf.ref
>
It's metadata file for TSDL description. I will rename it to "metadata"

>
> ? This is only an example as I am not really sure what role this file
> plays.
>
> Notes:
>
> 1) I have found in other parts of rtems-tools.git having the config
> directory of
> files separated from the other sources makes installing into the shared
> tree
> simpler.
>
> 2) The tools currently in rtems-tools.git can be run with the same command
> line
> options from a built repo with an absolute path or when installed under a
> prefix. This is something to consider when referencing configuration files.
>
> Okay, Chris. Thanks for the review.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 17/06/2019 13:14, Ravindra Kumar Meena wrote:

Hi Sebastian,

Thanks for sharing the blog. It was very helpful.
https://lttng.org/blog/2014/11/25/tracing-bare-metal-systems/

As you suggested to look into the Trace Compass tutorial. I checked it's 
metadata file. The file looks similar to the metadata file I wrote.


I have attached the Trace Compass tutorial file. Please have a look at 
it. In the file, you will find that there are 1160 events added. I think 
we will have to add rtems 512 system reserved events which are defined 
in /misc/record/recorddata.h.


I would like to know your point of view.


In which file format this the attached file? I have problems to read it 
with a text editor.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Comment added

[Sebastian Huber]

On 17/06/2019 12:45, Ravindra Kumar Meena wrote:



On Mon, Jun 17, 2019 at 1:45 PM Sebastian Huber 
> wrote:


On 16/06/2019 20:13, Ravindra Meena wrote:
 > ---
 >   misc/CTF/record-ctf.ref | 55
+
 >   1 file changed, 37 insertions(+), 18 deletions(-)
 >
 > diff --git a/misc/CTF/record-ctf.ref b/misc/CTF/record-ctf.ref
 > index a27757c..bdb9648 100644
 > --- a/misc/CTF/record-ctf.ref
 > +++ b/misc/CTF/record-ctf.ref
[...]
 >   clock {
 > -    name = ctf_clock;
 > -    freq = 1000;
 > -    offset_s = 1421703448;
 > +    name = ctf_clock; /* name of montonic clock */
 > +    freq = 1000; /* frequency, in HZ */

Why 1000Hz?

The freq field is the initial frequency of the clock, in Hz. If the freq 
field is not present, the frequency is assumed to be 10 
(providing clock increment of 1 ns). I set to 1000HZ just for getting 
started.


This clock is for timestamps. For which timestamps is it?




 > +    offset_s = 1421703448;

What is this for an offset?

This offset is a difference between the beginning of clock and the 
actual start of the clock. The event will be recorded just after the offset.


Sorry, I don't know what this means. What is the beginning of the clock 
and what is the actual start?





 >   };
 >
 > +/*
 > + *  A reference to the clock added within an integer type
 > + */
 > +
 >   typealias integer {
 >       size = 64;
 >       map = clock.ctf_clock.value;
 >   } := ctf_clock_int_t;

Why does this start with "ctf_"?

ctf_clock is the name of clock struct I created just above this. It is a 
reference to the clock name.


In case you can freely define names, then please don't include "ctf" in 
it. This suggests that this name is somehow part of the CTF specification.





 >
 > +/*
 > + * Trace stream packet having header and context.
 > + *
 > + * @param event.header includes id(unique identifier of stream)
and timestamp.
 > + * @param packet.context includes clock timestamp, cpu id, event
and event data.
 > + */
 > +
 >   stream {
 >       id = 0;
 > +    event.header := struct {
 > +        uint32_t id;

What is this for an id?

It is a unique identifier for stream header. There will be many streams 
so in order to identify the streams I have set the id here.


Could you please elaborate this a bit more. What is the purpose of this 
identifier? How generates the streams? Why can there be many streams? 
Who creates the identifiers?





 > +        ctf_clock_int_t timestamp;

Timestamp of what?

  It is the timestamp of the stream header. 


It is obvious that this is the timestamp of the stream header. Who 
generates this timestamp and when?


It is different from event 
header. The event heder can have a beginning  and ending timestamp.



 > +    };
 >       packet.context := struct {
 >               ctf_clock_int_t timestamp;
 >               uint32_t cpu;
 >               uint32_t event;
 >               uint64_t data;
 >       };
 > -    event.header := struct {
 > -        uint32_t id;
 > -        ctf_clock_int_t timestamp;
 > -    };
 >   };
 >
 >   event {
 > -    id = 0;
 > -    name = "ctf_event";
 > -    stream_id = 0;
 > +    id = 0; /* event id
 > +    name = "ctf_event"; /* event name */
 > +    stream_id = 0; /* signifies stream id which event is
supposed to concat with events */
 >       fields := struct {
 > -        uint32_t a;
 > -        uint16_t b;
 > -        string c;
 > +        uint32_t a; /*event 1*/
 > +        uint16_t b; /*event 2*/
 > +        string c; /*event 3*/

What are events 1, 2, 3?

I have added this event just for getting started. I thought it would be 
better to get it reviewed this much TSDL code.


Adding some random data is just confusing. It should be the TSDL of a 
record item stream. As I said before, you have two options with respect 
to the timestamp clock. You can


1. use the timestamps based on CPU clock cycles

OR

2. use the timestamps after some post-processing based on CLOCK_MONOTONIC.

You have to explain what you use.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> In which file format this the attached file? I have problems to read it
> with a text editor.
>
I used gedit to open the file. The editor will take little time to load the
file and will show encoding problem but still, you can view the file
content with gedit.

I used "gedit metadata" command to open the file.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 17/06/2019 13:38, Ravindra Kumar Meena wrote:

In which file format this the attached file? I have problems to read it
with a text editor.

I used gedit to open the file. The editor will take little time to load 
the file and will show encoding problem but still, you can view the file 
content with gedit.


I used "gedit metadata" command to open the file.


What is the SHA512 checksum of the file you can edit?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > I used gedit to open the file. The editor will take little time to load
> > the file and will show encoding problem but still, you can view the file
> > content with gedit.
> >
> > I used "gedit metadata" command to open the file.
>
> What is the SHA512 checksum of the file you can edit?
>
>
9556e2f193ed6075ac5f7642c4d83b9a60dfe80bdb2952b2a43675c49dbad00620c7c673982e79a0a03801ea83261b56e5200456ba0751222d4a28e32e34870c


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 17/06/2019 13:46, Ravindra Kumar Meena wrote:

 > I used gedit to open the file. The editor will take little time
to load
 > the file and will show encoding problem but still, you can view
the file
 > content with gedit.
 >
 > I used "gedit metadata" command to open the file.

What is the SHA512 checksum of the file you can edit?

9556e2f193ed6075ac5f7642c4d83b9a60dfe80bdb2952b2a43675c49dbad00620c7c673982e79a0a03801ea83261b56e5200456ba0751222d4a28e32e34870c 


Ok, I received the same file. kwrite complains that the file contains 
invalid UTF-8 sequences.


Is this the TSDL description of a Linux kernel trace which can be 
consumed by Trace Compass?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > What is the SHA512 checksum of the file you can edit?
> >
> >
> 9556e2f193ed6075ac5f7642c4d83b9a60dfe80bdb2952b2a43675c49dbad00620c7c673982e79a0a03801ea83261b56e5200456ba0751222d4a28e32e34870c
>
>
> Ok, I received the same file. kwrite complains that the file contains
> invalid UTF-8 sequences.
>
Okay

>
> Is this the TSDL description of a Linux kernel trace which can be
> consumed by Trace Compass?
>
Yes.
Alternatively, you can download the file [1]. After extracting [1] you will
find many metadata files. I sent you the metadata file residing in
"101-trace-navigation-in-tracecompass" folder.

[1]
https://github.com/tuxology/tracevizlab/blob/master/labs/TraceCompassTutorialTraces.tgz
-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 17/06/2019 14:01, Ravindra Kumar Meena wrote:

 >     What is the SHA512 checksum of the file you can edit?
 >
 >

9556e2f193ed6075ac5f7642c4d83b9a60dfe80bdb2952b2a43675c49dbad00620c7c673982e79a0a03801ea83261b56e5200456ba0751222d4a28e32e34870c


Ok, I received the same file. kwrite complains that the file contains
invalid UTF-8 sequences.

Okay


Is this the TSDL description of a Linux kernel trace which can be
consumed by Trace Compass?

Yes.
Alternatively, you can download the file [1]. After extracting [1] you 
will find many metadata files. I sent you the metadata file residing in 
"101-trace-navigation-in-tracecompass" folder.


[1] 
https://github.com/tuxology/tracevizlab/blob/master/labs/TraceCompassTutorialTraces.tgz


It seems the metadata files are somehow packetized. They contain plain 
text mixed in with binary data.


Could you please investigate which file format is used for the metadata 
files (e.g. ask on a lttng mailing list)?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Comment added

[Chris Johns]

On 17/6/19 8:50 pm, Ravindra Kumar Meena wrote:
> 
> I wonder if there should be a top level trace directory to gather all the 
> trace
> pieces in one place. I think trace is important enough to have this 
> status. So
> this file could be ...
> 
>  trace/config/ctf/record-ctf.ref
> 
> or
> 
>  trace/config/record-ctf.ref
> 
> It's metadata file for TSDL description. I will rename it to "metadata" 

What about "record-ctf.tsdl"? Metadata is a bit too general.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Comment added

[Sebastian Huber]

On 17/06/2019 14:41, Chris Johns wrote:

On 17/6/19 8:50 pm, Ravindra Kumar Meena wrote:


 I wonder if there should be a top level trace directory to gather all the 
trace
 pieces in one place. I think trace is important enough to have this 
status. So
 this file could be ...

  trace/config/ctf/record-ctf.ref

 or

  trace/config/record-ctf.ref

It's metadata file for TSDL description. I will rename it to "metadata"


What about "record-ctf.tsdl"? Metadata is a bit too general.


I am not sure in which file this will end up. In the Trace Compass 
tutorial the files are name "metadata". We should try to figure out how 
a lttng session names the files.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

17th June work Summary:
I sent a patch containing commented code. I had a discussion about metadata
file with Sebastian. Raised a query on lttng asking about the file format
of metadata.



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Adding support for new Ethernet PHY

[Jonathan Brandmeyer]

What does it take to support a new Ethernet PHY in rtems-libbsd?  We've got
a board with a TI DP83867 family member on it, which appears to have some
support in FreeBSD.  How can that get pulled into a particular rtems-libbsd
BSP?

Thanks,
-Jonathan Brandmeyer
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Adding support for new Ethernet PHY

[Christian Mauderer]

On 17/06/2019 18:16, Jonathan Brandmeyer wrote:
> What does it take to support a new Ethernet PHY in rtems-libbsd?  We've
> got a board with a TI DP83867 family member on it, which appears to have
> some support in FreeBSD.  How can that get pulled into a particular
> rtems-libbsd BSP?
> 
> Thanks,
> -Jonathan Brandmeyer
> 

Hello Jonathan,

if there is already a PHY driver for that PHY, you basically just follow
the steps from "How to Import Code from FreeBSD" in the libbsd
CONTRIBUTING.md. PHYs should be quite simple so it would be about:

- Add the files to libbsd.py
- Run ./freebsd-to-rtems.py -R and ./freebsd-to-rtems.py
- Commit the _unchanged_ imported files.
- Commit libbsd.py and (if necessary) changes.
- Add the driver reference to nexus-devices (if it is a officially
supported BSP) or to your application.

If it is supported, it should be most likely one of the files in
freebsd-org/sys/dev/mii. But to be honest: I didn't find it on a quick
look. Where did you find the support?

On the other hand: The DP83867E seems to have the default registers. If
you only need basic support without any extras, the generic ukphy (short
for UnKnown PHY) driver should work.

Best regards

Christian Mauderer
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Adding support for new Ethernet PHY

[Jonathan Brandmeyer]

I ran into some device tree support for this phy in
sys/gnu/dts/include/dt-bindings/net/ti-dp83867.h  It looks like
configuration information that would be fed to the generic mii_fdt
driver somehow.

Thanks for the tip re: ukphy.  What exactly does "basic support
without any extras" entail?  The test environment uses standard
gigabit workgroup switches.  So as long as it comes up in a
full-duplex gigabit mode, we're happy.

On Mon, Jun 17, 2019 at 12:09 PM Christian Mauderer  wrote:
>
> On 17/06/2019 18:16, Jonathan Brandmeyer wrote:
> > What does it take to support a new Ethernet PHY in rtems-libbsd?  We've
> > got a board with a TI DP83867 family member on it, which appears to have
> > some support in FreeBSD.  How can that get pulled into a particular
> > rtems-libbsd BSP?
> >
> > Thanks,
> > -Jonathan Brandmeyer
> >
>
> Hello Jonathan,
>
> if there is already a PHY driver for that PHY, you basically just follow
> the steps from "How to Import Code from FreeBSD" in the libbsd
> CONTRIBUTING.md. PHYs should be quite simple so it would be about:
>
> - Add the files to libbsd.py
> - Run ./freebsd-to-rtems.py -R and ./freebsd-to-rtems.py
> - Commit the _unchanged_ imported files.
> - Commit libbsd.py and (if necessary) changes.
> - Add the driver reference to nexus-devices (if it is a officially
> supported BSP) or to your application.
>
> If it is supported, it should be most likely one of the files in
> freebsd-org/sys/dev/mii. But to be honest: I didn't find it on a quick
> look. Where did you find the support?
>
> On the other hand: The DP83867E seems to have the default registers. If
> you only need basic support without any extras, the generic ukphy (short
> for UnKnown PHY) driver should work.
>
> Best regards
>
> Christian Mauderer



-- 
Jonathan Brandmeyer
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Adding support for new Ethernet PHY

[Christian Mauderer]

On 17/06/2019 20:35, Jonathan Brandmeyer wrote:
> I ran into some device tree support for this phy in
> sys/gnu/dts/include/dt-bindings/net/ti-dp83867.h  It looks like
> configuration information that would be fed to the generic mii_fdt
> driver somehow.
> 
> Thanks for the tip re: ukphy.  What exactly does "basic support
> without any extras" entail?  The test environment uses standard
> gigabit workgroup switches.  So as long as it comes up in a
> full-duplex gigabit mode, we're happy.

>From a quick look at the registers that should work. The PHY seems to
support some extras like special LED settings or impedance control. But
as long as you don't need that or set it with strapping options I would
expect it to work out of the box.

But even if you need some extra bits: PHY drivers are not that
complicated most of the time. For an example you can have a look at the
rtemsbsd/sys/dev/mii/ksz8091rnb_50MHz.c in libbsd. That PHY needed some
special bits for a 50MHz clock source. Otherwise it not much more than
the ukphy driver.

> 
> On Mon, Jun 17, 2019 at 12:09 PM Christian Mauderer  
> wrote:
>>
>> On 17/06/2019 18:16, Jonathan Brandmeyer wrote:
>>> What does it take to support a new Ethernet PHY in rtems-libbsd?  We've
>>> got a board with a TI DP83867 family member on it, which appears to have
>>> some support in FreeBSD.  How can that get pulled into a particular
>>> rtems-libbsd BSP?
>>>
>>> Thanks,
>>> -Jonathan Brandmeyer
>>>
>>
>> Hello Jonathan,
>>
>> if there is already a PHY driver for that PHY, you basically just follow
>> the steps from "How to Import Code from FreeBSD" in the libbsd
>> CONTRIBUTING.md. PHYs should be quite simple so it would be about:
>>
>> - Add the files to libbsd.py
>> - Run ./freebsd-to-rtems.py -R and ./freebsd-to-rtems.py
>> - Commit the _unchanged_ imported files.
>> - Commit libbsd.py and (if necessary) changes.
>> - Add the driver reference to nexus-devices (if it is a officially
>> supported BSP) or to your application.
>>
>> If it is supported, it should be most likely one of the files in
>> freebsd-org/sys/dev/mii. But to be honest: I didn't find it on a quick
>> look. Where did you find the support?
>>
>> On the other hand: The DP83867E seems to have the default registers. If
>> you only need basic support without any extras, the generic ukphy (short
>> for UnKnown PHY) driver should work.
>>
>> Best regards
>>
>> Christian Mauderer
> 
> 
> 

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Comment added

[Sebastian Huber]

On 17/06/2019 13:36, Sebastian Huber wrote:



 > +    offset_s = 1421703448;

    What is this for an offset?

This offset is a difference between the beginning of clock and the 
actual start of the clock. The event will be recorded just after the 
offset.


Sorry, I don't know what this means. What is the beginning of the clock 
and what is the actual start?


From the CTF specification we have:

"The offset_s and offset fields indicate the offset from POSIX.1 Epoch, 
1970-01-01 00:00:00 + (UTC), to the zero of value of the clock. The 
offset_s field is in seconds. The offset field is in (1/freq) units."


https://diamon.org/ctf/#spec8

The CLOCK_MONOTONIC in RTEMS is based on the boot time. So, if you want 
to give an offset value you have to figure out the CLOCK_REALTIME value 
at boot time of the system. This is currently a secondary problem. I 
would just omit the offset for now.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
>
> It seems the metadata files are somehow packetized. They contain plain
> text mixed in with binary data.
>
> Could you please investigate which file format is used for the metadata
> files (e.g. ask on a lttng mailing list)?
>
I raised a query on lltng for the same. The community is very active.
This is what they said:
https://lists.lttng.org/pipermail/lttng-dev/2019-June/029056.html

Please have a look

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

Hi,

About a week ago I raised a query on decoder(source plugin) examples shared
by them.

They suggested that if we plan to use Babeltrace 2 plugin system, the
metadata file
will be generated based on the trace representation given by the source
plugin.

https://lists.lttng.org/pipermail/lttng-dev/2019-June/029057.html

Please have a look

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 18/06/2019 08:07, Ravindra Kumar Meena wrote:


It seems the metadata files are somehow packetized. They contain plain
text mixed in with binary data.

Could you please investigate which file format is used for the metadata
files (e.g. ask on a lttng mailing list)?

I raised a query on lltng for the same. The community is very active.
This is what they said:
https://lists.lttng.org/pipermail/lttng-dev/2019-June/029056.html

Please have a look


Did the answers help you to understand how the metadata is generated?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Update newlib/libc/search directory

[Vaibhav Gupta]

Hello
Yesterday I was trying to update newlib/libc/search directory.
.

- Updatinghash.hwill create need to update following files:
- hash_page.c :now requires libc_private.h
- hash_bigkey.c
- hash_buf.c
- hash.c : requires namespace.h, un-namespace.h present in
posix, hence modify Makefile.am
- hash_fun.c
- hcreate_r.c :  now requires hsearch.h/hsearch_r.c (elix 2)
- hcreate.c
- hash_log2.c

Andnewlib/libc/include/search.h   was ported from NetBSD and
not from FreeBSD, so there

is change in data structures, which are giving compilation errors.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 18/06/2019 08:14, Ravindra Kumar Meena wrote:

Hi,

About a week ago I raised a query on decoder(source plugin) examples 
shared by them.


They suggested that if we plan to use Babeltrace 2 plugin system, the 
metadata file
will be generated based on the trace representation given by the source 
plugin.


https://lists.lttng.org/pipermail/lttng-dev/2019-June/029057.html

Please have a look


Yes, this is why I asked about a TSDL description last week:

https://lists.rtems.org/pipermail/devel/2019-June/026101.html

Creating the metadata is one of the first actions a plugin must do.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > It seems the metadata files are somehow packetized. They contain
> plain
> > text mixed in with binary data.
> >
> > Could you please investigate which file format is used for the
> metadata
> > files (e.g. ask on a lttng mailing list)?
> >
> > I raised a query on lltng for the same. The community is very active.
> > This is what they said:
> > https://lists.lttng.org/pipermail/lttng-dev/2019-June/029056.html
> >
> > Please have a look
>
> Did the answers help you to understand how the metadata is generated?
>
I didn't understand much. [1] [2] [3] are the same the thing I was
following to write the metadata file.

I had a look at [4] and [5] code. It appears to me that metadata is
generated is directly from the code.

[1] https://diamon.org/ctf/#spec7
[2] https://diamon.org/ctf/#spec7.4
[3] https://diamon.org/ctf/#specC
[4]
https://github.com/efficios/barectf/blob/a3ebf5855c025a86ebc2d62cbda1338461e84c5a/barectf/tsdl182gen.py
[5]
https://github.com/lttng/lttng-tools/blob/c8e0c5f5d94fb574f4e5d7518f0f8e6f984dfe3d/src/bin/lttng-sessiond/ust-metadata.c

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > About a week ago I raised a query on decoder(source plugin) examples
> > shared by them.
> >
> > They suggested that if we plan to use Babeltrace 2 plugin system, the
> > metadata file
> > will be generated based on the trace representation given by the source
> > plugin.
> >
> > https://lists.lttng.org/pipermail/lttng-dev/2019-June/029057.html
> >
> > Please have a look
>
> Yes, this is why I asked about a TSDL description last week:
>
> https://lists.rtems.org/pipermail/devel/2019-June/026101.html
>
> Creating the metadata is one of the first actions a plugin must do
>
Okay.

I sent you one metadata file which had 1160 events. So should I add the
rtems 512 events in metadata?

The problem I am facing here is how to relate the metadata file with rtems
event record item?


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel