Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

>I am not sure you can do this without providing your own babeltrace
source component in a separate plugin to what is already available. If
the trace is not converted to a useful CTF format.

Yes. The blog post is merely to demonstrate how to use babeltrace. We will
not be dealing with text trace input to babeltrace. I am reading up on how
to create a customized plugin for RTEMS binary trace output for this.
Transporting ASCII files off the target will be a heavy operation hence
this is avoided.

Thanks



On Thu, Jul 5, 2018 at 4:04 AM, Guillaume Champagne <
guillaume.champa...@polymtl.ca> wrote:

> On Tue, 2018-07-03 at 07:50 +0530, Vidushi Vashishth wrote:
> > > 3. Clearly document your modifications in separate commit messages.
> >
> > > 4. Add a Makefile to build it automatically.
> >
> > I will push commits to a fork of the rtems. Have given a link to the
> > repository in the readme.md of the Tracing repo. Will that be okay?
> >
> > > 6. Document the steps involved in the tracing, e.g. trace data
> > generation on the RTEMS target, transfer of the data to the
> > development host, conversion of trace data in format X to Y using
> > tool Z, etc. Document the interfaces between the different steps and
> > what runs on the RTEMS target and what runs on the development host.
> >
> > Done
> >
> > > To get the trace data from the simulator to the development host,
> > you can just dump the data via printf() and parse it on the host.
> > This is slow, but enough for a test scenario.
> >
> > I have tested the babeltrace conversion by saving the console output
> > to a text file on host manually (https://vidushivashishth.github.io/e
> > ighthpost/). Can I use sockets to transport the traces from target to
> > host instead? Will that be feasible? I have already created a client
> > and server side program and tested a text file transfer. This is
> > working.
> >
>
> I tried the example in your blog post which works without `sudo` with
> babeltrace 2.0.0-pre4 on fedora. However, I am not sure the ctf output
> is correct. Each line in the original trace is dumped in a ctf event
> named "string" since the example uses the source `text.dmesg`. This
> source is usually used to parse the output of the dmesg linux tool [1].
>
> string: { }, { str = "0:00:26.7031882952081911  0a010002 [  2/  2]
> > malloc((size_t) 0130)" }
> string: { }, { str = "0:00:26.703324403 136108  0a010002 [  2/  2]
> < malloc => (void*) 0x219be08" }
> [..]
>
> This should be changed to actually split the data into correct CTF
> event field and header, like lttng-ust does:
>
> [18:14:22.611410669] (+0.01652) station12.dorsal.polymtl.ca
> lttng_ust_cyg_profile:func_entry: { cpu_id = 5 }, { vpid = 21117, vtid =
> 21117, procname = "demo" }, { addr = 0x7FF848DB6E21, call_site =
> 0x7FF848DB7856 }
> [..]
>
> I am not sure you can do this without providing your own babeltrace
> source component in a separate plugin to what is already available. If
> the trace is not converted to a useful CTF format, Trace Compass won't
> provide any useful analyses since it won't know what the event or the
> payload means.
>
> [1] http://man7.org/linux/man-pages/man7/babeltrace-source.text.dmesg.7
> .html
>
> Guillaume
>
> > > Either we should use barectf to generate CTF traces in RTEMS, we
> > > should implement our own CTF generator in RTEMS, or we should
> > provide
> > > a converter for running babeltrace on a host (Linux/MacOS/etc) to
> > > convert from RTEMS trace linker format to CTF.
> >
> > I am implementing the last option.
> >
> > On Tue, Jul 3, 2018 at 1:37 AM, Gedare Bloom 
> > wrote:
> > > On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber
> > >  wrote:
> > > > Hello Vidushi,
> > > >
> > > > On 29/06/18 09:44, Vidushi Vashishth wrote:
> > > >>
> > > >>
> > > >> >Could you please create a self-contained repository
> > > which
> > > >> contains
> > > >>
> > > >> >* a README
> > > >>
> > > >> >* a simple RTEMS application which runs on a simulator
> > > BSP
> > > >>
> > > >> >* the stuff that makes it possible to view the trace
> > > output
> > > >> (it is not a problem if it doesn't work, but all pieces
> > > should
> > > >> be included)
> > > >>
> > > >> >The repo

Re: GSoC IRC Meeting reschedule: 7/4 to 7/3

[Vidushi Vashishth]

Hi!

I am sorry for the late update. I might not be able to make it due to a
prescheduled doctor's appointment. I will try to get in on the go.
I will update the progress on the wiki page as well. I will send a separate
progress mail on the mailing list if need be.

Thanks

On Mon, Jul 2, 2018 at 10:51 PM, Gedare Bloom  wrote:

> Hello All,
>
> We will hold the weekly IRC meeting on Tuesday 7/3 (tomorrow!) instead
> of 7/4 at the same usual time (10am Eastern Daylight Time) due to the
> US holiday on 7/4. Joel will likely lead the meeting.
>
> Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

> 3. Clearly document your modifications in separate commit messages.

> 4. Add a Makefile to build it automatically.

I will push commits to a fork of the rtems. Have given a link to the
repository in the readme.md of the Tracing repo. Will that be okay?

> 6. Document the steps involved in the tracing, e.g. trace data generation
on the RTEMS target, transfer of the data to the development host,
conversion of trace data in format X to Y using tool Z, etc. Document the
interfaces between the different steps and what runs on the RTEMS target
and what runs on the development host.

Done

> To get the trace data from the simulator to the development host, you can
just dump the data via printf() and parse it on the host. This is slow, but
enough for a test scenario.

I have tested the babeltrace conversion by saving the console output to a
text file on host manually (https://vidushivashishth.github.io/eighthpost/).
Can I use sockets to transport the traces from target to host instead? Will
that be feasible? I have already created a client and server side program
and tested a text file transfer. This is working.

> Either we should use barectf to generate CTF traces in RTEMS, we
> should implement our own CTF generator in RTEMS, or we should provide
> a converter for running babeltrace on a host (Linux/MacOS/etc) to
> convert from RTEMS trace linker format to CTF.

I am implementing the last option.

On Tue, Jul 3, 2018 at 1:37 AM, Gedare Bloom  wrote:

> On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber
>  wrote:
> > Hello Vidushi,
> >
> > On 29/06/18 09:44, Vidushi Vashishth wrote:
> >>
> >>
> >> >Could you please create a self-contained repository which
> >> contains
> >>
> >> >* a README
> >>
> >> >* a simple RTEMS application which runs on a simulator BSP
> >>
> >> >* the stuff that makes it possible to view the trace output
> >> (it is not a problem if it doesn't work, but all pieces should
> >> be included)
> >>
> >> >The repository should not be a clone of some larger project.
> >> It may contain external references as submodules.
> >>
> >> Okay. Got it. I will update you when its done.
> >>
> >>
> >> Ok, do you have a time estimate for this? Which parts are missing?
> >>
> >>
> >> Viewing the trace output is buggy right now. I will have to combine the
> >> rest. I will push the required things in the repository by end of today
> and
> >> notify you.
> >>
> >
> > the stuff you published here
> >
> > https://github.com/VidushiVashishth/Tracing
> >
> > yesterday (this is not "by end of today") is not much considering this
> the
> > 8th week of the GSoC project.
> >
> > You seem to have imported cpukit/libmisc/shell/main_rtrace.c and
> modified
> > it. The modifications are not visible in the repository history. Why did
> yo
> > copy this file out of the RTEMS sources at all?
> >
> > There is no Makefile (or similar). You have to read the documentation to
> > build it. You cannot copy and past the instructions to build it since it
> > contains your local paths.
> >
> > The test data is generated with user input.
> >
> > How can I transfer the test data generated on the simulator to my host
> > development system?
> >
> > I asked for a self-contained repository, with"the stuff that makes it
> > possible to view the trace output". This is missing.
> >
> > Could you please:
> >
> > 1. Not copy sources out of the RTEMS repository. Before you do this, ask
> on
> > the mailing list and explain why have have to do it.
> >
> > 2. If you import things, then import the original files and state the
> > origin.
> >
> > 3. Clearly document your modifications in separate commit messages.
> >
> > 4. Add a Makefile to build it automatically.
> >
> > 5. Add the missing stuff that makes it possible to view the trace
> output. If
> > something is not available yet, then no problem. Just document the
> > interfaces and what it is supposed to do.
> >
> > 6. Document the steps involved in the tracing, e.g. trace data
> generation on
> > the RTEMS target, transfer of the data to the development host,
> conversion
> > of trace data in format X to Y using tool Z, etc. Document the interfaces
> > between the different steps and what runs on the RTEMS target and what
> runs
> > on the development host.
> >
> > To get the trace data from the 

Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

Hi!

https://github.com/VidushiVashishth/Tracing

This is the required repository. I read up the POSIX API documentation to
understand that nothing of the like of system( ) would work on rtems since
its a single process os.
The main_rtrace.c in the given repository currently consists of this wrong
approach. There are two options that I can do.

1) See if babelltrace C API would work and replace the system call logic
with this.

OR

2) Continue with the barectf approach. PFA the metadata file that I came up
with for this purpose.
A typical trace will consist a single stream. Events inside the stream will
have three fields for name of the function, two input argument values or
one return value (according to whether the event describes the entry or
exit of the function being traced)

Things to be done in this method:
1) Convert the metada file to a yaml configuration file. (almost done)
2) Inspect the header and c file generated by barectf for this configuration
3) Create a trace linker generator which binds these barectf function calls
to tracing.

Checkout the barectf documentation to see how it works:

I will send the yaml configuration too when its done. What do you suggest I
should do?

References:
https://github.com/efficios/barectf/wiki/Using-barectf

Thanks

On Sun, Jul 1, 2018 at 7:12 AM, Chris Johns  wrote:

>
> On 29 Jun 2018, at 5:44 pm, Vidushi Vashishth  wrote:
>
> >Could you please create a self-contained repository which contains
>>>
>>> >* a README
>>>
>>> >* a simple RTEMS application which runs on a simulator BSP
>>>
>>> >* the stuff that makes it possible to view the trace output (it is not
>>> a problem if it doesn't work, but all pieces should be included)
>>>
>>> >The repository should not be a clone of some larger project. It may
>>> contain external references as submodules.
>>>
>>> Okay. Got it. I will update you when its done.
>>>
>>
>> Ok, do you have a time estimate for this? Which parts are missing?
>
>
> Viewing the trace output is buggy right now. I will have to combine the
> rest. I will push the required things in the repository by end of today and
> notify you.
>
>
> Did this happen?
>
> Chris
>


metadata
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

>
> >Could you please create a self-contained repository which contains
>>
>> >* a README
>>
>> >* a simple RTEMS application which runs on a simulator BSP
>>
>> >* the stuff that makes it possible to view the trace output (it is not a
>> problem if it doesn't work, but all pieces should be included)
>>
>> >The repository should not be a clone of some larger project. It may
>> contain external references as submodules.
>>
>> Okay. Got it. I will update you when its done.
>>
>
> Ok, do you have a time estimate for this? Which parts are missing?


Viewing the trace output is buggy right now. I will have to combine the
rest. I will push the required things in the repository by end of today and
notify you.

> Is visualization with Trace Compass a goal of this project?
>>
>> No it isn't. Trace generation in CTF is a goal.
>>
>
> What are the consumers of this CTF? Why do we need it? What is the benefit
> for the RTEMS users?


CTF allows traces to be natively generated by any C/C++ application or
system, as well as by bare-metal (hardware) components. CTF is a flexible
tracing format with a range of configurable datatypes. This allows CTF to
describe any binary structure. Also since CTF is a binary trace format it
is faster to write. The post processing (eg Trace Compass) and real time
monitoring tools available with it are valuable.


On Fri, Jun 29, 2018 at 10:35 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/06/18 19:41, Vidushi Vashishth wrote:
>
>> >Could you please create a self-contained repository which contains
>>
>> >* a README
>>
>> >* a simple RTEMS application which runs on a simulator BSP
>>
>> >* the stuff that makes it possible to view the trace output (it is not a
>> problem if it doesn't work, but all pieces should be included)
>>
>> >The repository should not be a clone of some larger project. It may
>> contain external references as submodules.
>>
>> Okay. Got it. I will update you when its done.
>>
>
> Ok, do you have a time estimate for this? Which parts are missing?
>
>
>> >Did you modify babeltrace?
>>
>> No I did not.
>>
>
> Ok, this is good.
>
>
>> >Why do you need a very recent babeltrace for your work?
>>
>> I haven't tested the code with other versions of babeltrace. I cant say
>> why it does not work with others. I ll try to test the code with other
>> versions and identify what's wrong.
>>
>
> If it doesn't work with the babeltrace shipped with standard
> distributions, then this a slight burden to get started for users. It is
> not a high priority issue at the moment.
>
>
>> > Is visualization with Trace Compass a goal of this project?
>>
>> No it isn't. Trace generation in CTF is a goal.
>>
>
> What are the consumers of this CTF? Why do we need it? What is the benefit
> for the RTEMS users?
>
>
> --
> 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 - Tracing] Status Update

[Vidushi Vashishth]

>Could you please create a self-contained repository which contains

>* a README

>* a simple RTEMS application which runs on a simulator BSP

>* the stuff that makes it possible to view the trace output (it is not a
problem if it doesn't work, but all pieces should be included)

>The repository should not be a clone of some larger project. It may
contain external references as submodules.

Okay. Got it. I will update you when its done.

>Did you modify babeltrace?

No I did not.

>Why do you need a very recent babeltrace for your work?

I haven't tested the code with other versions of babeltrace. I cant say why
it does not work with others. I ll try to test the code with other versions
and identify what's wrong.

> Is visualization with Trace Compass a goal of this project?

No it isn't. Trace generation in CTF is a goal.

On Thu, Jun 28, 2018 at 11:43 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/06/18 07:42, Vidushi Vashishth wrote:
>
>> >which use case does this address? What is the connection to an RTEMS
>> application?
>> This converts the trace buffering of the fileio sample testcase output to
>> CTF. This pertains to the function tracing testcase. The CTF stream
>> generated records the entry and exit of the calloc, malloc, realloc and
>> free functions and also the values of the arguments and return values.
>>
>
> Could you please create a self-contained repository which contains
>
> * a README
>
> * a simple RTEMS application which runs on a simulator BSP
>
> * the stuff that makes it possible to view the trace output (it is not a
> problem if it doesn't work, but all pieces should be included)
>
> The repository should not be a clone of some larger project. It may
> contain external references as submodules.
>
>
>> >Why do I need sudo to run the commands?
>> The command needs permission to create a directory for the traces. The
>> command did not work without this.
>>
>
> It worked without sudo in my clone. Using sudo for this kind of stuff
> would be a very severe usability issue from my point of view.
>
>
>> >Why do I need your babeltrace? Not being able to use a tool from a
>> standard distribution makes it harder to do RTEMS tracing.
>> I wanted to work on integrating barectf with RTEMS trace linker instead.
>> I documented the approach in: https://vidushivashishth.githu
>> b.io/sixthpost/.
>>
>
> Could you please also post your stuff on the devel@rtems.org mailing
> list. I don't have time to look for blog posts actively.
>
> Did you modify babeltrace?
>
> Why do you need a very recent babeltrace for your work?
>
> I was stuck on deciding the yaml configuration input for the process and
>> sent out an email for this discussion on the mailing list as well. I have
>> however finally created one. I can continue work on the barectf approach if
>> that is okay with you? I will start a new thread on this with the
>> configuration file I have chosen?
>>
>
> I need a demo projects which puts all the pieces together. This is all to
> abstract to me.
>
>
>> >What can I do with a metadata stream and the CTF trace stream?
>> These can be transported to the host and then viewed using Trace Compass.
>>
>> I lost some time trying to figure things out on my own. I will be more
>> frequent in communicating places where I am stuck. Apologies for the same.
>>
>
> Is visualization with Trace Compass a goal of this project?
>
>
> --
> 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 - Tracing] Status Update

[Vidushi Vashishth]

>which use case does this address? What is the connection to an RTEMS
application?
This converts the trace buffering of the fileio sample testcase output to
CTF. This pertains to the function tracing testcase. The CTF stream
generated records the entry and exit of the calloc, malloc, realloc and
free functions and also the values of the arguments and return values.

>Why do I need sudo to run the commands?
The command needs permission to create a directory for the traces. The
command did not work without this.

>Why do I need your babeltrace? Not being able to use a tool from a
standard distribution makes it harder to do RTEMS tracing.
I wanted to work on integrating barectf with RTEMS trace linker instead. I
documented the approach in: https://vidushivashishth.github.io/sixthpost/.
I was stuck on deciding the yaml configuration input for the process and
sent out an email for this discussion on the mailing list as well. I have
however finally created one. I can continue work on the barectf approach if
that is okay with you? I will start a new thread on this with the
configuration file I have chosen?

>What can I do with a metadata stream and the CTF trace stream?
These can be transported to the host and then viewed using Trace Compass.

I lost some time trying to figure things out on my own. I will be more
frequent in communicating places where I am stuck. Apologies for the same.


On Thu, Jun 28, 2018 at 10:42 AM, Vidushi Vashishth 
wrote:

> >Run on what? RTEMS?
> yes.
>
> >Are there any RTEMS repos with your work?
> I havent pushed my code since it is throwing errors. Should I push it
> nonetheless for you to see? Or create another repo?
>
> >RTEMS does not support `system()`.
> Does RTEMS support fdopen or popen? I am trying to execute the babeltrace
> command on the shell, from within the c program. I could use babeltrace C
> API instead but Gedare suggested during a meeting that it might not be
> integrable with RTEMS.
>
> >Could please explain how you are integrating `program.c`?
> I have created a new shell utility function in the
> *rtems/cpukit/libmisc/shell/main_rtrace.c*. It saves the raw trace buffer
> to a file and then uses the logic of `program.c`
> to convert it into CTF traces.
>
>
> On Thu, Jun 28, 2018 at 10:07 AM, Chris Johns  wrote:
>
>> On 28/06/2018 13:48, Vidushi Vashishth wrote:
>> >
>> > Sorry for the delay. I had been trying to make the code run.
>>
>> Run on what? RTEMS?
>>
>> > https://github.com/VidushiVashishth/babeltrace/tree/master/Demo
>>
>> Are there any RTEMS repos with your work?
>>
>> > This is a demonstration of the how to use babeltrace to convert rtems
>> traces. I
>> > have integrated the program.c code in the rtems main_rtrace.c file.
>> This is
>> > throwing some errors that I am working on.
>>
>> RTEMS does not support `system()`.
>>
>> Could please explain how you are integrating `program.c`?
>>
>> Thanks
>> Chris
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

>Run on what? RTEMS?
yes.

>Are there any RTEMS repos with your work?
I havent pushed my code since it is throwing errors. Should I push it
nonetheless for you to see? Or create another repo?

>RTEMS does not support `system()`.
Does RTEMS support fdopen or popen? I am trying to execute the babeltrace
command on the shell, from within the c program. I could use babeltrace C
API instead but Gedare suggested during a meeting that it might not be
integrable with RTEMS.

>Could please explain how you are integrating `program.c`?
I have created a new shell utility function in the
*rtems/cpukit/libmisc/shell/main_rtrace.c*. It saves the raw trace buffer
to a file and then uses the logic of `program.c`
to convert it into CTF traces.


On Thu, Jun 28, 2018 at 10:07 AM, Chris Johns  wrote:

> On 28/06/2018 13:48, Vidushi Vashishth wrote:
> >
> > Sorry for the delay. I had been trying to make the code run.
>
> Run on what? RTEMS?
>
> > https://github.com/VidushiVashishth/babeltrace/tree/master/Demo
>
> Are there any RTEMS repos with your work?
>
> > This is a demonstration of the how to use babeltrace to convert rtems
> traces. I
> > have integrated the program.c code in the rtems main_rtrace.c file. This
> is
> > throwing some errors that I am working on.
>
> RTEMS does not support `system()`.
>
> Could please explain how you are integrating `program.c`?
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

Hi!

Sorry for the delay. I had been trying to make the code run.
https://github.com/VidushiVashishth/babeltrace/tree/master/Demo
This is a demonstration of the how to use babeltrace to convert rtems
traces. I have integrated the program.c code in the rtems main_rtrace.c
file. This is throwing some errors that I am working on. I will push the
changes to the main_rtrace.c file in a couple of hours.

Thanks

On Wed, Jun 27, 2018 at 10:31 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> On 22/06/18 03:16, Vidushi Vashishth wrote:
>
>> Progress so far:
>>
>> - Still working on adding rtrace shell capability to convert RTEMS traces
>> into CTF. There has been progress which I will push to (
>> https://github.com/VidushiVashishth/rtems) by end of today.
>>
>
> I don't see an update in this repository from you. Could you please
> publish your work today so that I can try it out.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim,
> <https://maps.google.com/?q=dress+:+Dornierstr.+4,+D-82178+Puchheim,=gmail=g>
> 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

[GSOC - Tracing] Status Update

[Vidushi Vashishth]

Hi!

I have updated the weekly status of my work on the GSoC tracking page. Here
is a summary of it:

Progress so far:

- Still working on adding rtrace shell capability to convert RTEMS traces
into CTF. There has been progress which I will push to (
https://github.com/VidushiVashishth/rtems) by end of today.
- I have gone through libdebugger's abstraction of transport interfaces in
preparation of the second phase. I need to deliver a transport mechanism to
transfer buffers to the host in this phase.

Next up:

- Submit mergeable code for CTF integration
- Write a blog on the possible transport mechanisms to be explored (
https://vidushivashishth.github.io/seventhpost/)
- Setup qemu for ARM as working environment to try qemu fat files and file
transfer as a method of transport.

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

Re: [PATCH v7 2/2] Adding Trace Documentation

[Vidushi Vashishth]

The latest trace documentation images patch is version 5.

Thanks

On Thu, Jun 14, 2018 at 7:47 PM, Vidushi Vashishth 
wrote:

> - Updates #3454
> - This commit adds Tracing Framework Chapter in the RTEMS User Manual
> - It comprises of subchapters on RTEMS Trace Linker, Capture Engine, Trace
>   generation techniques explaining trace generation using Trace Buffering
> and
>   Printk generators and sample demonstrations.
> ---
>  user/index.rst |   2 +
>  user/tracing/captureengine.rst | 169 ++
>  user/tracing/examples.rst  | 199 +
>  user/tracing/index.rst |  29 +++
>  user/tracing/introduction.rst  | 103 +
>  user/tracing/tracelinker.rst   | 494 ++
> +++
>  6 files changed, 996 insertions(+)
>  create mode 100644 user/tracing/captureengine.rst
>  create mode 100644 user/tracing/examples.rst
>  create mode 100644 user/tracing/index.rst
>  create mode 100644 user/tracing/introduction.rst
>  create mode 100644 user/tracing/tracelinker.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index 8cbcd1b..a764fe8 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/
> .
>
> tools/index
>
> +tracing/index
> +
> support/index
>
> glossary/index
> diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.
> rst
> new file mode 100644
> index 000..8eaed3b
> --- /dev/null
> +++ b/user/tracing/captureengine.rst
> @@ -0,0 +1,169 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: Copyright (c) 2018 Vidushi Vashishth <
> vidushivashisht...@gmail.com>
> +.. comment: All rights reserved.
> +
> +.. _capturengine:
> +
> +Capture Engine
> +**
> +
> +Capture Engine is a trace tool built inside the RTEMS operating system.
> Capture
> +Engine is designed to cause the lowest load on the system when operating.
> Hence
> +it does not effect RTEMS when operating or when disabled. It binds to
> RTEMS at
> +runtime and does not require RTEMS or your application to be rebuilt in
> order
> +to use it.
> +
> +The Capture Engine's sample testcase for the `sparc/erc32` is available in
> +build directory created when building RTEMS in the path
> +file: `sparc-rtems5/c/erc32/testsuites/samples`. In order to access the
> capture
> +testcase perform the following set of operations inside the RTEMS build
> +directory.
> +
> +.. code-block:: shell
> +
> +  $ cd /sparc-rtems5/c/erc32/testsuites/samples
> +  $ sparc-rtems5-run ./capture.exe
> +
> +
> +  *** BEGIN OF TEST CAPTURE ENGINE ***
> +  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
> +  *** TEST STATE: USER_INPUT
> +  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> +  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
> +  Press any key to start capture engine (20s remaining)
> +  Press any key to start capture engine (19s remaining)
> +  Press any key to start capture engine (18s remaining)
> +
> +  Monitor ready, press enter to login.
> +
> +  1-rtems $
> +
> +Capture Engine comes with a set of commands to perform various actions.
> +
> +Capture Engine Commands
> +---
> +
> +1) ``copen ``: Used to initialize the Capture Engine with the
> +   trace buffer size in bytes. By default the Capture Engine is not
> initialized
> +   and not running.
> +
> +2) ``cwceil ``: Capture Engine filter used to put an upper
> +   limit on the event priority to be captured.
> +
> +3) ``cwfloor ``: Capture Engine filter used to put a lower
> +   limit on the event priority to be captured.
> +
> +4) ``cwglob ``: Enable or disable the global watch.
> +
> +5) ``cenable``: Enables the Capture Engine. Capture Engine is by default
> +   disabled after being opened.
> +
> +6) ``cdisable``: Disables the Capture Engine.
> +
> +7) ``ctlist``: Lists the watch and trigger configurations.
> +
> +8) ``ctrace``: Dumps the recorded traces. By default this command
> displays 24
> +   trace records. Repeated use of this command will display all the
> recorded
> +   traces.
> +
> +9) ``cwadd ``: Add watch on a particular task.
> +
> +10) ``cwtctl  ``: Enable or disable watch on a
> particular
> +task.
> +
> +11) ``ctset``: Used to set a trigger. The general form of the command is:
> +
> +``ctset [-?] type [to name/id] [from] [from name/id]``
> +
> +`type` in the above command refers to the type of trigger needed. The
> types of
> +triggers that currently exist are:

[PATCH v7 2/2] Adding Trace Documentation

[Vidushi Vashishth]

- Updates #3454
- This commit adds Tracing Framework Chapter in the RTEMS User Manual
- It comprises of subchapters on RTEMS Trace Linker, Capture Engine, Trace
  generation techniques explaining trace generation using Trace Buffering and
  Printk generators and sample demonstrations.
---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 169 ++
 user/tracing/examples.rst  | 199 +
 user/tracing/index.rst |  29 +++
 user/tracing/introduction.rst  | 103 +
 user/tracing/tracelinker.rst   | 494 +
 6 files changed, 996 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..8eaed3b
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,169 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2018 Vidushi Vashishth 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. Capture
+Engine is designed to cause the lowest load on the system when operating. Hence
+it does not effect RTEMS when operating or when disabled. It binds to RTEMS at
+runtime and does not require RTEMS or your application to be rebuilt in order
+to use it.
+
+The Capture Engine's sample testcase for the `sparc/erc32` is available in
+build directory created when building RTEMS in the path
+file: `sparc-rtems5/c/erc32/testsuites/samples`. In order to access the capture
+testcase perform the following set of operations inside the RTEMS build
+directory.
+
+.. code-block:: shell
+
+  $ cd /sparc-rtems5/c/erc32/testsuites/samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions.
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the
+   trace buffer size in bytes. By default the Capture Engine is not initialized
+   and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper
+   limit on the event priority to be captured.
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower
+   limit on the event priority to be captured.
+
+4) ``cwglob ``: Enable or disable the global watch.
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default
+   disabled after being opened.
+
+6) ``cdisable``: Disables the Capture Engine.
+
+7) ``ctlist``: Lists the watch and trigger configurations.
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24
+   trace records. Repeated use of this command will display all the recorded
+   traces.
+
+9) ``cwadd ``: Add watch on a particular task.
+
+10) ``cwtctl  ``: Enable or disable watch on a particular
+task.
+
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+`type` in the above command refers to the type of trigger needed. The types of
+triggers that currently exist are:
+
+- switch  : a context switch from one task to another task
+- create  : the executing task creates a task
+- start   : the executing task starts a task
+- restart : the executing task restarts a task
+- delete  : the executing task deletes a task
+- begin   : a task is beginning
+- exitted : a task is exitting
+
+Example
+---
+
+The following is a sample run of the capture testsuite. The `test1` command on
+the Capture Engine Command Line Interface (CLI) makes the `RMON` task invoke a
+call to the `capture_test_1()` command. This function (in the `test1.c` source
+code) creates and starts three tasks : `CT1a`, `CT1b` and `CT1c`. These tasks
+are passed the object id of a semaphore as a task argument. This run through
+traces the context switches between these tasks. ``cwceil`` and ``cwfloor`` are
+set to a narrow

Re: [PATCH v5 2/2] Adding Trace Docuemntation

[Vidushi Vashishth]

>There should be a ticket associated with your project that it would
>make sense to add a line in the commit message: "Updates #2xxx"?

I ll make a documentation related ticket and reframe the commit message.

>Is all of this Chris' writing? Or did you write some of this? You
>should put your copyright and current year on the files with words
>that you create, if any

Some of this is Chris, some is mine and some is with changes in Chris'
documentation. I will make the copyright changes too.

>These two sections "Function Wrapping" and "Function Signatures" seem
>misplaced. I suspect they belong before Generators, maybe merged with
>the "Function Sections" part?

I will merge them with the Function Section.

On Wed, Jun 13, 2018 at 6:49 PM, Gedare Bloom  wrote:

> Sorry, I didn't see v6, but my comments still apply. I suspect v7 will
> be mergeable.
>
> On Wed, Jun 13, 2018 at 9:18 AM, Gedare Bloom  wrote:
> > I think we're almost there. ;) A bit more below:
> >
> > On Wed, Jun 13, 2018 at 5:22 AM, Vidushi Vashishth 
> wrote:
> >> - Completed Trace Linker Section
> >> - Added Trace Examples section
> >> - Removed CTF section
> >> - Removed Use cases section
> >> - Incorporated changes asked by Chris
> >
> > It would be best to provide the "summary of changes" in reply to the
> > patch, and instead continue to have a useful commit message that will
> > make sense when someone looks in the git-log. For example, looking in
> > the log and seeing "Removed CTF section" one would ask where that was
> > to begin with. Also, that you incorporated asked for changes can be
> > omitted, since this is usually the case for all commits. So make sure
> > your commit message only accurately reflects what is in the commit.
> >
> > There should be a ticket associated with your project that it would
> > make sense to add a line in the commit message: "Updates #2xxx"?
> >
> >> ---
> >>  user/index.rst |   2 +
> >>  user/tracing/captureengine.rst | 182 +++
> >>  user/tracing/examples.rst  | 185 +++
> >>  user/tracing/index.rst |  30 +++
> >>  user/tracing/introduction.rst  | 105 +
> >>  user/tracing/tracelinker.rst   | 501 ++
> +++
> >>  6 files changed, 1005 insertions(+)
> >>  create mode 100644 user/tracing/captureengine.rst
> >>  create mode 100644 user/tracing/examples.rst
> >>  create mode 100644 user/tracing/index.rst
> >>  create mode 100644 user/tracing/introduction.rst
> >>  create mode 100644 user/tracing/tracelinker.rst
> >>
> >> diff --git a/user/index.rst b/user/index.rst
> >> index 8cbcd1b..a764fe8 100644
> >> --- a/user/index.rst
> >> +++ b/user/index.rst
> >> @@ -52,6 +52,8 @@ to the Community Project hosted at
> http://www.rtems.org/.
> >>
> >> tools/index
> >>
> >> +tracing/index
> >> +
> >> support/index
> >>
> >> glossary/index
> >> diff --git a/user/tracing/captureengine.rst
> b/user/tracing/captureengine.rst
> >> new file mode 100644
> >> index 000..b4c1123
> >> --- /dev/null
> >> +++ b/user/tracing/captureengine.rst
> >> @@ -0,0 +1,182 @@
> >> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> >> +
> >> +.. comment: Copyright (c) 2016 Chris Johns 
> >
> > Is all of this Chris' writing? Or did you write some of this? You
> > should put your copyright and current year on the files with words
> > that you create, if any
> >
> >> +.. comment: All rights reserved.
> >> +
> >> +.. _capturengine:
> >> +
> >> +Capture Engine
> >> +**
> >> +
> >> +Capture Engine is a trace tool built inside the RTEMS operating
> system. Capture
> >> +Engine is designed to cause the lowest load on the system when
> operating. Hence
> >> +it does not effect RTEMS when operating or when disabled. It binds to
> RTEMS at
> >> +runtime and does not require RTEMS or your application to be rebuilt
> in order
> >> +to use it.
> >> +
> >> +The Capture Engine's sample testcase for the `sparc/erc32` is
> available in
> >> +build directory created when building RTEMS in the path
> >> +file: `sparc-rtems5/c/erc32/testsuites/samples` directory.
> >> +In order to access the capture testcase perform the following set of
> >> 

Re: [PATCH v5 1/2] Adding Trace Docuemntation Images

[Vidushi Vashishth]

>Do we have PDF versions of the PNG images? PNG images are not really good
for PDF generation.

I downloaded the images from the RTEMS website :
https://devel.rtems.org/wiki/Developer/Tracing
Should I convert them to pdf and send?


On Wed, Jun 13, 2018 at 3:06 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> the patch set looks good. Would you mind fixing also the white space
> errors:
>
> git am \[PATCH\ v5\ *
> Applying: Adding Trace Docuemntation Images
> Applying: Adding Trace Docuemntation
> .git/rebase-apply/patch:44: trailing whitespace.
> Capture Engine is a trace tool built inside the RTEMS operating system.
> Capture
> .git/rebase-apply/patch:48: trailing whitespace.
> to use it.
> .git/rebase-apply/patch:49: trailing whitespace.
>
> .git/rebase-apply/patch:50: trailing whitespace.
> The Capture Engine's sample testcase for the `sparc/erc32` is available in
> .git/rebase-apply/patch:57: trailing whitespace.
>
> warning: squelched 147 whitespace errors
> warning: 152 lines add whitespace errors.
>
> Do we have PDF versions of the PNG images? PNG images are not really good
> for PDF generation.
>
> --
> 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

[PATCH v6 2/2] Adding Trace Documentation

[Vidushi Vashishth]

Removed white spaces
---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 169 ++
 user/tracing/examples.rst  | 183 +++
 user/tracing/index.rst |  29 +++
 user/tracing/introduction.rst  | 104 +
 user/tracing/tracelinker.rst   | 498 +
 6 files changed, 985 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..f2389af
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,169 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. Capture
+Engine is designed to cause the lowest load on the system when operating. Hence
+it does not effect RTEMS when operating or when disabled. It binds to RTEMS at
+runtime and does not require RTEMS or your application to be rebuilt in order
+to use it.
+
+The Capture Engine's sample testcase for the `sparc/erc32` is available in
+build directory created when building RTEMS in the path
+file: `sparc-rtems5/c/erc32/testsuites/samples` directory.
+In order to access the capture testcase perform the following set of
+operations inside the RTEMS build directory.
+
+.. code-block:: shell
+
+  $ cd /sparc-rtems5/c/erc32/testsuites/samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions.
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the
+   trace buffer size in bytes. By default the Capture Engine is not initialized
+   and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper
+   limit on the event priority to be captured.
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower
+   limit on the event priority to be captured.
+
+4) ``cwglob ``: Enable or disable the global watch.
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default
+   disabled after being opened.
+
+6) ``cdisable``: Disables the Capture Engine.
+
+7) ``ctlist``: Lists the watch and trigger configurations.
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24
+   trace records. Repeated use of this command will display all the recorded
+   traces.
+
+9) ``cwadd ``: Add watch on a particular task.
+
+10) ``cwtctl  ``: Enable or disable watch on a particular
+task.
+
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+`type` in the above command refers to the type of trigger needed. The types of
+triggers that currently exist are:
+
+- switch  : a context switch from one task to another task
+- create  : the executing task creates a task
+- start   : the executing task starts a task
+- restart : the executing task restarts a task
+- delete  : the executing task deletes a task
+- begin   : a task is beginning
+- exitted : a task is exitting
+
+Example
+---
+
+The following is a sample run of the capture testsuite. The `test1` command on
+the Capture Engine Command Line Interface (CLI) makes the `RMON` task invoke a
+call to the `capture_test_1()` command. This function (in the `test1.c` source
+code) creates and starts three tasks : `CT1a`, `CT1b` and `CT1c`. These tasks
+are passed the object id of a semaphore as a task argument. This run through
+traces the context switches between these tasks. ``cwceil`` and ``cwfloor`` are
+set to a narrow range of task priorities to avoid creating noise from a large
+number of context switches between tasks we are not interested in.
+
+.. code:: shell
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  

Re: [PATCH v4 2/2] Adding trace documentation

[Vidushi Vashishth]

>Oh that maybe a mistake. Which section?

I cross checked, it does'nt exist in the current documentation. I think I
must have misinterpreted it.

>Yes please that would be good then we can have some documentation for what
>exists pushed to master.

I have sent the v5 patches. Please review and let me know.

Thanks

On Wed, Jun 13, 2018 at 8:50 AM, Chris Johns  wrote:

> On 13/06/2018 13:04, Vidushi Vashishth wrote:
> >
> > I have made the changes you suggested.
>
> Thanks.
>
> > I am still working on CTF support.
> >
> >>> +  $ ../samples
> >>What is this command?
> >
> > This is not a command. It is used to show which directory we are in.
> This method
> > was used in the quickstart section. But I have removed this.
>
> Oh that maybe a mistake. Which section?
>
> >
> >>There is some doco that would be good to have in master now and
> somewhich needs
> >>to wait. Should this be split do we can do this?
> >
> > I could complete the tracing examples page and the trace linker page and
> remove
> > the CTF portion and submit another patch?
>
> Yes please that would be good then we can have some documentation for what
> exists pushed to master.
>
> > The section on use cases and CTF are under development.
>
> I understand and it is great to see the documentation you have already on
> the
> subject.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v5 2/2] Adding Trace Docuemntation

[Vidushi Vashishth]

- Completed Trace Linker Section
- Added Trace Examples section
- Removed CTF section
- Removed Use cases section
- Incorporated changes asked by Chris
---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 182 +++
 user/tracing/examples.rst  | 185 +++
 user/tracing/index.rst |  30 +++
 user/tracing/introduction.rst  | 105 +
 user/tracing/tracelinker.rst   | 501 +
 6 files changed, 1005 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..b4c1123
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,182 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. 
Capture 
+Engine is designed to cause the lowest load on the system when operating. Hence
+it does not effect RTEMS when operating or when disabled. It binds to RTEMS at
+runtime and does not require RTEMS or your application to be rebuilt in order
+to use it. 
+ 
+The Capture Engine's sample testcase for the `sparc/erc32` is available in 
+build directory created when building RTEMS in the path
+file: `sparc-rtems5/c/erc32/testsuites/samples` directory.
+In order to access the capture testcase perform the following set of
+operations inside the RTEMS build directory.
+
+.. code-block:: shell
+   
+  $ cd /sparc-rtems5/c/erc32/testsuites/samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
+  a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions. 
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the 
+   trace buffer size in bytes. By default the Capture Engine is not 
initialized 
+   and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper 
+   limit on the event priority to be captured. 
+
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower 
+   limit on the event priority to be captured.
+
+
+4) ``cwglob ``: Enable or disable the global watch. 
+
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default 
+   disabled after being opened.
+
+
+6) ``cdisable``: Disables the Capture Engine. 
+
+
+7) ``ctlist``: Lists the watch and trigger configurations. 
+
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24 
+   trace records. Repeated use of this command will display all the recorded 
+   traces. 
+
+9) ``cwadd ``: Add watch on a particular task.
+
+
+10) ``cwtctl  ``: Enable or disable watch on a particular 
+task.
+
+  
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+`type` in the above command refers to the type of trigger needed. The types of 
+triggers that currently exist
+are:
+
+- switch  : a context switch from one task to another task
+- create  : the executing task creates a task
+- start   : the executing task starts a task
+- restart : the executing task restarts a task
+- delete  : the executing task deletes a task
+- begin   : a task is beginning
+- exitted : a task is exitting
+
+Example
+---
+
+The following is a sample run of the capture testsuite. The `test1` command on
+the Capture Engine Command Line Interface (CLI) makes the `RMON` task invoke a
+call to the `capture_test_1()` command. This function (in the `test1.c` source
+code) creates and starts three tasks : `CT1a`, `CT1b` and `CT1c`. These tasks
+are passed the object id of a semaphore as a task argument. This run through
+traces the context switches between these tasks. ``cwceil`` and ``cwfloor`` are
+set to a narrow range of task priorities to avoid creating noise from a large
+number of context 

Re: [PATCH v4 2/2] Adding trace documentation

[Vidushi Vashishth]

Hi

I have made the changes you suggested. I am still working on CTF support.

>> +  $ ../samples
>What is this command?

This is not a command. It is used to show which directory we are in. This
method was used in the quickstart section. But I have removed this.

>There is some doco that would be good to have in master now and somewhich
needs
>to wait. Should this be split do we can do this?

I could complete the tracing examples page and the trace linker page and
remove the CTF portion and submit another patch?
The section on use cases and CTF are under development.

On Wed, Jun 13, 2018 at 7:26 AM, Chris Johns  wrote:

> Hi,
>
> This documentation looks good and I welcome this being done and added to
> the
> RTEMS project.
>
> I have some comments below I hope are easy to resolve.
>
> Thanks
> Chris
>
> On 13/06/2018 11:23, Vidushi Vashishth wrote:
> > ---
> >  user/index.rst |   2 +
> >  user/tracing/captureengine.rst | 184 ++
> >  user/tracing/examples.rst  |  12 ++
> >  user/tracing/index.rst |  29 +
> >  user/tracing/introduction.rst  | 182 ++
> >  user/tracing/tracelinker.rst   | 287 ++
> +++
> >  user/tracing/usecases.rst  | 117 +
> >  7 files changed, 813 insertions(+)
> >  create mode 100644 user/tracing/captureengine.rst
> >  create mode 100644 user/tracing/examples.rst
> >  create mode 100644 user/tracing/index.rst
> >  create mode 100644 user/tracing/introduction.rst
> >  create mode 100644 user/tracing/tracelinker.rst
> >  create mode 100644 user/tracing/usecases.rst
> >
> > diff --git a/user/index.rst b/user/index.rst
> > index 8cbcd1b..a764fe8 100644
> > --- a/user/index.rst
> > +++ b/user/index.rst
> > @@ -52,6 +52,8 @@ to the Community Project hosted at
> http://www.rtems.org/.
> >
> >   tools/index
> >
> > +tracing/index
> > +
> >   support/index
> >
> >   glossary/index
> > diff --git a/user/tracing/captureengine.rst
> b/user/tracing/captureengine.rst
> > new file mode 100644
> > index 000..64b501a
> > --- /dev/null
> > +++ b/user/tracing/captureengine.rst
> > @@ -0,0 +1,184 @@
> > +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> > +
> > +.. comment: Copyright (c) 2016 Chris Johns 
> > +.. comment: All rights reserved.
> > +
> > +.. _capturengine:
> > +
> > +Capture Engine
> > +**
> > +
> > +Capture Engine is a trace tool built inside the RTEMS operating system.
> Capture
> > +Engine is designed to cause the lowest load on the system when
> operating. Hence
> > +it does not effect RTEMS when operating or when disabled. It binds to
> RTEMS at
> > +runtime and does not require RTEMS or your application to be rebuilt in
> order
> > +to use it.
> > +
> > +The Capture Engine's sample testcase for the `sparc/erc32` is available
> in the
> > +"$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples"
>
>
> Please use relative paths in the case. The
> "$HOME/development/rtems/kernel/erc32" is specific to a user and while I
> have
> used this in the User Manual it does not mean it is mandatory.
>
> I suggest:
>
> The Capture Engine's sample testcase for the `sparc/erc32` is available in
> the
> build direct created when building RTEMS in the path
> file:`sparc-rtems5/c/erc32/testsuites/samples` directory.
>
> Also please use file:`path` for paths and files.
>
> > +directory, provided you followed the installation directions of the
> quickstart
> > +section. In order to access the capture testcase perform the following
> set of
> > +operations.
> > +
> > +.. code-block:: shell
> > +
> > +  $ cd
> > +  $HOME/development/rtems/kernel/erc32/sparc-rtems5/c/
> erc32/testsuites/samples
>
> Please make relative.
>
> > +  $ ../samples
>
> What is this command?
>
> > +  $ sparc-rtems5-run ./capture.exe
> > +
> > +
> > +  *** BEGIN OF TEST CAPTURE ENGINE ***
> > +  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
> > +  *** TEST STATE: USER_INPUT
> > +  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> > +  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> > +  a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
> > +  Press any key to start capture engine (20s remaining)
> > +  Press any key to start capture engine (19s remaining)
> > +  Press any key to start capture engine (18s remai

Re: [PATCH v3 2/2] Adding trace documentation

[Vidushi Vashishth]

I was using Sublime text. It appeared okay on the editor. I have changed my
editor and sent another patch.

Thanks.

On Tue, Jun 12, 2018 at 9:46 PM, Gedare Bloom  wrote:

> On Tue, Jun 12, 2018 at 11:15 AM, Vidushi Vashishth 
> wrote:
> >
> > Adjusted line length to 79-80
> > ---
> >  user/index.rst |   2 +
> >  user/tracing/captureengine.rst | 188 ++
> >  user/tracing/examples.rst  |  12 ++
> >  user/tracing/index.rst |  33 +
> >  user/tracing/introduction.rst  | 184 ++
> >  user/tracing/tracelinker.rst   | 294 ++
> +++
> >  user/tracing/usecases.rst  | 129 ++
> >  7 files changed, 842 insertions(+)
> >  create mode 100644 user/tracing/captureengine.rst
> >  create mode 100644 user/tracing/examples.rst
> >  create mode 100644 user/tracing/index.rst
> >  create mode 100644 user/tracing/introduction.rst
> >  create mode 100644 user/tracing/tracelinker.rst
> >  create mode 100644 user/tracing/usecases.rst
> >
> > diff --git a/user/index.rst b/user/index.rst
> > index 8cbcd1b..a764fe8 100644
> > --- a/user/index.rst
> > +++ b/user/index.rst
> > @@ -52,6 +52,8 @@ to the Community Project hosted at
> http://www.rtems.org/.
> >
> > tools/index
> >
> > +tracing/index
> > +
> > support/index
> >
> > glossary/index
> > diff --git a/user/tracing/captureengine.rst
> b/user/tracing/captureengine.rst
> > new file mode 100644
> > index 000..b80d7d0
> > --- /dev/null
> > +++ b/user/tracing/captureengine.rst
> > @@ -0,0 +1,188 @@
> > +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> > +
> > +.. comment: Copyright (c) 2016 Chris Johns 
> > +.. comment: All rights reserved.
> > +
> > +.. _capturengine:
> > +
> > +Capture Engine
> > +**
> > +
> > +Capture Engine is a trace tool built inside the RTEMS operating system.
> Capture
> > +Engine
>
> It is not right to just blanket wrap to 80 characters. This one word
> on a line by itself is no good. Many text editors can make the
> wrapping work in a nice way, but I don't know what editor you use. For
> example, I use vim, and text formatting can be done by highlighting
> text in Visual mode and using 'gq' command to reformat.
>
> > +is designed to cause the lowest load on the system when operating.
> Hence it
> > +does not
> > +effect RTEMS when operating or when disabled. It binds to RTEMS at
> runtime and
> > +does not
> > +require RTEMS or your application to be rebuilt in order to use it.
> > +
> > +The Capture Engine's sample testcase for the `sparc/erc32` is available
> in the
> > +"$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/
> erc32/testsuites/samples"
> > +directory,
> > +provided you followed the installation directions of the quickstart
> section. In
> > +order to
> > +access the capture testcase perform the following set of operations.
> > +
> > +.. code-block:: shell
> > +
> > +  $ cd
> > +  $HOME/development/rtems/kernel/erc32/sparc-rtems5/c/
> erc32/testsuites/samples
> > +  $ ../samples
> > +  $ sparc-rtems5-run ./capture.exe
> > +
> > +
> > +  *** BEGIN OF TEST CAPTURE ENGINE ***
> > +  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
> > +  *** TEST STATE: USER_INPUT
> > +  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> > +  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> > +  a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
> > +  Press any key to start capture engine (20s remaining)
> > +  Press any key to start capture engine (19s remaining)
> > +  Press any key to start capture engine (18s remaining)
> > +
> > +  Monitor ready, press enter to login.
> > +
> > +  1-rtems $
> > +
> > +Capture Engine comes with a set of commands to perform various actions.
> > +
> > +Capture Engine Commands
> > +---
> > +
> > +1) ``copen ``: Used to initialize the Capture Engine with
> the
> > +   trace buffer size in bytes. By default the Capture Engine is not
> initialized
> > +   and not running.
> > +
> > +2) ``cwceil ``: Capture Engine filter used to put an
> upper
> > +   limit on the event priority to be captured.
> > +
> > +
> > +3) ``cwfloor ``: Capture Engine filter used to put a
> lower
> > +   limit on the event priority to be captured.
> > +
> > +
>

[PATCH v4 2/2] Adding trace documentation

[Vidushi Vashishth]

---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 184 ++
 user/tracing/examples.rst  |  12 ++
 user/tracing/index.rst |  29 +
 user/tracing/introduction.rst  | 182 ++
 user/tracing/tracelinker.rst   | 287 +
 user/tracing/usecases.rst  | 117 +
 7 files changed, 813 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst
 create mode 100644 user/tracing/usecases.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..64b501a
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,184 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. 
Capture 
+Engine is designed to cause the lowest load on the system when operating. Hence
+it does not effect RTEMS when operating or when disabled. It binds to RTEMS at
+runtime and does not require RTEMS or your application to be rebuilt in order
+to use it. 
+ 
+The Capture Engine's sample testcase for the `sparc/erc32` is available in the
+"$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples" 
+directory, provided you followed the installation directions of the quickstart
+section. In order to access the capture testcase perform the following set of
+operations.
+
+.. code-block:: shell
+
+  $ cd 
+  $HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples
+  $ ../samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
+  a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions. 
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the 
+   trace buffer size in bytes. By default the Capture Engine is not 
initialized 
+   and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper 
+   limit on the event priority to be captured. 
+
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower 
+   limit on the event priority to be captured.
+
+
+4) ``cwglob ``: Enable or disable the global watch. 
+
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default 
+   disabled after being opened.
+
+
+6) ``cdisable``: Disables the Capture Engine. 
+
+
+7) ``ctlist``: Lists the watch and trigger configurations. 
+
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24 
+   trace records. Repeated use of this command will display all the recorded 
+   traces. 
+
+9) ``cwadd ``: Add watch on a particular task.
+
+
+10) ``cwtctl  ``: Enable or disable watch on a particular 
+task.
+
+  
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+'type' in the above command refers to the type of trigger needed. The types of 
+triggers that currently exist
+are:
+
+- switch  : a context switch from one task to another task
+- create  : the executing task creates a task
+- start   : the executing task starts a task
+- restart : the executing task restarts a task
+- delete  : the executing task deletes a task
+- begin   : a task is beginning
+- exitted : a task is exitting
+
+Example
+---
+
+The following is a sample run of the capture testsuite. The test1 command on 
the
+Capture Engine Command Line Interface (CLI) makes the 'RMON' task invoke a 
call 
+to the 'capture_test_1()' command. This function (in the 'test1.c' source code)
+creates and starts three tasks : 'CT1a', 'CT1b' and 'CT1c'. These tasks are 
+passed the object id of a semaphore as a task argument. This run through traces
+the context switches between these tasks. ``cwceil`` and ``cwfloor`` are set 
to 
+a narrow range of task priorities to avoid 

[PATCH v3 2/2] Adding trace documentation

[Vidushi Vashishth]

Adjusted line length to 79-80
---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 188 ++
 user/tracing/examples.rst  |  12 ++
 user/tracing/index.rst |  33 +
 user/tracing/introduction.rst  | 184 ++
 user/tracing/tracelinker.rst   | 294 +
 user/tracing/usecases.rst  | 129 ++
 7 files changed, 842 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst
 create mode 100644 user/tracing/usecases.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..b80d7d0
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,188 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. 
Capture 
+Engine
+is designed to cause the lowest load on the system when operating. Hence it 
+does not
+effect RTEMS when operating or when disabled. It binds to RTEMS at runtime and 
+does not
+require RTEMS or your application to be rebuilt in order to use it. 
+ 
+The Capture Engine's sample testcase for the `sparc/erc32` is available in the
+"$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples" 
+directory,
+provided you followed the installation directions of the quickstart section. 
In 
+order to
+access the capture testcase perform the following set of operations.
+
+.. code-block:: shell
+
+  $ cd 
+  $HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples
+  $ ../samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
+  a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions. 
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the 
+   trace buffer size in bytes. By default the Capture Engine is not 
initialized 
+   and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper 
+   limit on the event priority to be captured. 
+
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower 
+   limit on the event priority to be captured.
+
+
+4) ``cwglob ``: Enable or disable the global watch. 
+
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default 
+   disabled after being opened.
+
+
+6) ``cdisable``: Disables the Capture Engine. 
+
+
+7) ``ctlist``: Lists the watch and trigger configurations. 
+
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24 
+   trace records. Repeated use of this command will display all the recorded 
+   traces. 
+
+9) ``cwadd ``: Add watch on a particular task.
+
+
+10) ``cwtctl  ``: Enable or disable watch on a particular 
+task.
+
+  
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+'type' in the above command refers to the type of trigger needed. The types of 
+triggers that currently exist
+are:
+
+- switch  : a context switch from one task to another task
+- create  : the executing task creates a task
+- start   : the executing task starts a task
+- restart : the executing task restarts a task
+- delete  : the executing task deletes a task
+- begin   : a task is beginning
+- exitted : a task is exitting
+
+Example
+---
+
+The following is a sample run of the capture testsuite. The test1 command on 
+the Capture Engine Command Line Interface (CLI) makes the 'RMON' task invoke
+a call to the 'capture_test_1()' command. This function (in the 
+'test1.c' source code) creates and starts three tasks : 'CT1a', 'CT1b' and 
+'CT1c'. These tasks are passed the object id of a semaphore as a task argument.
+This run through traces the context switches between these tasks.
+``cwceil`` and ``cwfloor`` are set to a narrow 

Re: [GSoC - Tracing] Status

[Vidushi Vashishth]

Hi!

>in case you receive comments for your patches the highest priority should
be to fix the problems with the patches and send the next revision of the
patch to the list, e.g. fixing trivial things like the line ?>length should
be done in a couple of minutes. If you think a comment is invalid or makes
no sense, then please say this also. The patch review process should be as
fast as possible.

I wasn't finished with the documentation and I intended to incorporate the
line length change in the next patch. I got caught up with the babeltrace
conversion hence did not work on the documentation patches. I am sorry you
feel unhappy about the visibility of my work. I will follow your
instructions more carefully. I will upload example codes to my github
repository and notify you.

>I need to know which tools I have to installon top of the standard RTEMS
tools on a normal Linux machine.

Babeltrace is the only tool you need to install for now. The instructions
to install it are mentioned in : http://diamon.org/babeltrace/
I will add these details to the github repository too. I will make the
necessary changes in the user manual as well.

On Tue, Jun 12, 2018 at 5:34 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> in case you receive comments for your patches the highest priority should
> be to fix the problems with the patches and send the next revision of the
> patch to the list, e.g. fixing trivial things like the line length should
> be done in a couple of minutes. If you think a comment is invalid or makes
> no sense, then please say this also. The patch review process should be as
> fast as possible.
>
> You posted the "[PATCH v2 2/2] Adding trace documentation" on 10th June
> and got a comment from Gedare on the same day. You acknowledged it on the
> same day and now two days later there is still no next revision of the
> patch.
>
> I am not happy with the visibility of your work. If you work on examples
> then please find a repository (the examples should be a part of RTEMS at
> some point in time) for this stuff which I can clone and try out.
>
> In order to try it out. I need to know which tools I have to installon top
> of the standard RTEMS tools on a normal Linux machine. This information
> should be available in the user manual. I don't need detailed installation
> steps. Just an overview, maybe with links to the external project
> documentation. From my point of view the installation section should be in
> one place and not scattered throughout several sections.
>
> --
> 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

[GSoC - Tracing] Status

[Vidushi Vashishth]

Hi!

Updating the status on the tracing project. I am working on a ctftrace
function in the main_rtrace.c file in rtems source code which will use the
libbabeltrace C API to convert the trace buffers and print the final CTF
onto the console. I am using a static metadata specific to the fileio
sample test case in this regard. I should be able to complete this in a day
or two.

I was going through a previous year student's GSoC project on tracing and
he had added metadata generation capability to the trace linker. There were
some improvements required in terms of utilizing user data types. I was
thinking I could work on these improvements next. He was a 2016 student.
Let me know if this is a good idea.

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

Re: [PATCH v2 2/2] Adding trace documentation

[Vidushi Vashishth]

>The formatting is the Emacs default for ReST. It would be nice to maintain
that format.

Oh yes I will fix that.


On Sun, Jun 10, 2018 at 5:56 PM, Chris Johns  wrote:

>
> > On 10 Jun 2018, at 8:32 pm, Gedare Bloom  wrote:
> >
> > I can't give a detailed review, but one possible problem I notice is
> > the line lengths. I think in the docs we also have 79/80 character
> > widths for lines. Please set your editor to hard-wrap at 79 or 80, and
> > break the long lines. (Unless I'm mistaken about the line length in
> > the doc files.)
>
> You are not mistaken.
>
> The formatting is the Emacs default for ReST. It would be nice to maintain
> that format.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 2/2] Adding trace documentation

[Vidushi Vashishth]

- Incorporated suggested changes (except making use case example as close to 
the actual output)
- Added trace linker section (to be completed)
- Added capture engine section
- Added trace buffering and printk trace generation in introduction
- Added trace examples section (to be completed)

The only tool to be installed is babeltrace which is in the introduction page 
under the babeltrace heading.
This documentation covers the following links:
1) https://devel.rtems.org/wiki/Developer/Tracing
2) https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
3) https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
4) 
https://devel.rtems.org/attachment/wiki/Developer/Tracing/Trace_Buffering/fileio-trace.ini
5) https://ftp.rtems.org/pub/rtems/people/chrisj/capture/capture-pc586.txt
6) http://diamon.org/ctf/
7) http://diamon.org/babeltrace/
---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 167 +++
 user/tracing/examples.rst  |  11 ++
 user/tracing/index.rst |  26 +
 user/tracing/introduction.rst  | 150 
 user/tracing/tracelinker.rst   | 253 +
 user/tracing/usecases.rst  | 110 ++
 7 files changed, 719 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst
 create mode 100644 user/tracing/usecases.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..49f8a58
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,167 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. 
Capture Engine
+is designed to cause the lowest load on the system when operating. Hence it 
does not
+effect RTEMS when operating or when disabled. It binds to RTEMS at runtime and 
does not
+require RTEMS or your application to be rebuilt in order to use it. 
+ 
+The Capture Engine's sample testcase for the `sparc/erc32` is available in the
+"$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples" 
directory,
+provided you followed the installation directions of the quickstart section. 
In order to
+access the capture testcase perform the following set of operations.
+
+.. code-block:: shell
+
+  $ cd 
$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples
+  $ ../samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions. 
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the 
trace buffer size in bytes. By default the Capture Engine is not initialized 
and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper 
limit on the event priority to be captured. 
+
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower 
limit on the event priority to be captured.
+
+
+4) ``cwglob ``: Enable or disable the global watch. 
+
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default 
disabled after being opened.
+
+
+6) ``cdisable``: Disables the Capture Engine. 
+
+
+7) ``ctlist``: Lists the watch and trigger configurations. 
+
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24 
trace records. Repeated use of this command will display all the recorded 
traces. 
+
+9) ``cwadd ``: Add watch on a particular task.
+
+
+10) ``cwtctl  ``: Enable or disable watch on a particular 
task.
+
+  
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+'type' in the above command refers to the type of trigger needed. The types of 
triggers that currently exist
+are:
+
+- switch  : a context switch from one task to another 

Re: [Tracing] Deciding the Yaml configuration for barectf input

[Vidushi Vashishth]

Hi!

Quick question. I tried to modify the printk trace generator to print the
output traces into a text file instead of the console. On running the
normal link and trace linker commands there are no compilation errors.
However when I run the application executable using GDB it says [Inferior 1
(process 42000) exited normally].

This is what I am doing to the code section of the rtld-print.ini's printk
generator:

static inline void rtld_pg_printk_entry(const char* func_name,
void*   func_addr)
{
  FILE* fp = fopen("trace.txt", "a");
  fprintf (fp, ">>> %s (0x%08x)\n", func_name, func_addr);
  fclose(fp);
}

Is there something wrong with this approach?

On Thu, Jun 7, 2018 at 2:00 PM, Vidushi Vashishth 
wrote:

> Hi Sebastian.
>
>
>> I still have problems to see the big picture. Would it be possible to
>> implement both approaches using a simple example?
>
>
> I am working on the babeltrace approach and using the fileio test case to
> track entry and exit of malloc, calloc, realloc and free functions. I will
> have something ready very soon.  I will keep you updated.
>
> Thanks!
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Tracing] Deciding the Yaml configuration for barectf input

[Vidushi Vashishth]

Hi Sebastian.


> I still have problems to see the big picture. Would it be possible to
> implement both approaches using a simple example?


I am working on the babeltrace approach and using the fileio test case to
track entry and exit of malloc, calloc, realloc and free functions. I will
have something ready very soon.  I will keep you updated.

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

Re: [Tracing] Deciding the Yaml configuration for barectf input

[Vidushi Vashishth]

Hey Guillaume!

>I am wondering what tools are currently used for visualizing the resulting
RTEMS trace, if any. And what are your plan on this aspect once you can
output CTF traces with >RTEMS?

RTEMS wiki pages do suggest using trace compass for the purpose of
visualization of traces [1]. It seems like a good choice.

>There is currently interest in providing support for generic RTOS support
in Trace Compass [1], which I'll be working on soon. If we could coordinate
on this aspect >regarding traced events, I think we could achieve
interesting things.

For sure! I look forward to it.

>Also, my two cent for your question is that you are much better
integrating CTF gen directly in RTEMS if modification to babeltrace source
code would be required. I think it >would be simpler to upstream your
changes that way.

Yes that would be simpler. But at some point in time I will have to decide
on a CTF structure for the output traces. I suspect this knowledge will
also be used when changing the babeltrace source code for RTEMS trace
format conversion. And hence the urgent need for advice :p

Thanks for the input:)

Vidushi

On Wed, Jun 6, 2018 at 11:16 PM, Guillaume Champagne <
guillaume.champa...@polymtl.ca> wrote:

> Hi Vidushi,
>
> I am not answering on the mailing list, because I am not sure if my
> questions were already answered previously.
>
> If I understand correctly, the first part of your GSOC project is to
> integrate CTF traces to kernel level event in RTEMS?
> I am wondering what tools are currently used for visualizing the resulting
> RTEMS trace, if any. And what are your plan on this aspect once you can
> output CTF traces with RTEMS?
>
> There is currently interest in providing support for generic RTOS support
> in Trace Compass [1], which I'll be working on soon. If we could coordinate
> on this aspect regarding traced events, I think we could achieve
> interesting things.
>
> Also, my two cent for your question is that you are much better
> integrating CTF gen directly in RTEMS if modification to babeltrace source
> code would be required. I think it would be simpler to upstream your
> changes that way.
>
> [1] http://tracecompass.org/
>
> Guillaume
>
> Vidushi Vashishth  a écrit :
>
>
> Hi!
>>
>> I have written a blog post  (https://vidushivashishth.gith
>> ub.io/sixthpost/)
>> summarizing two approaches to CTF generation that I can employ at this
>> point. I prefer on working with the barectf approach. The only blocker
>> that
>> exists with this approach is deciding on a YAML configuration [1] for
>> defining the structure of the CTF traces. This will be the input to the
>> barectf. I needed advice on how to go about this.
>>
>> References:
>> [1]
>> https://github.com/efficios/barectf/wiki/Writing-the-YAML-co
>> nfiguration-file
>>
>> Thanks,
>> Vidushi
>>
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[Tracing] Deciding the Yaml configuration for barectf input

[Vidushi Vashishth]

Hi!

I have written a blog post  (https://vidushivashishth.github.io/sixthpost/)
summarizing two approaches to CTF generation that I can employ at this
point. I prefer on working with the barectf approach. The only blocker that
exists with this approach is deciding on a YAML configuration [1] for
defining the structure of the CTF traces. This will be the input to the
barectf. I needed advice on how to go about this.

References:
[1]
https://github.com/efficios/barectf/wiki/Writing-the-YAML-configuration-file

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

Re: [PATCH] Adding tracing documentation in user manual

[Vidushi Vashishth]

I am just sending a revised version with incorporations of your
>> suggestions. I will create a fresh version 2 patch after everyone has
>> reviewed.
>>
>
> If you send revised version, then please send them as a separate patch
> with a new version. You can mention in the commit message what you changed
> in a particular version of the patch. For example:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06269.html
>
> There should be a section which tells me which tools I have to install.
>
> The new files need a proper copyright message mentioning the copyright
> owner.
>

Okay I will make these changes.

In contrast to the other documents the stuff in user uses subdirectories
> and separate files at a low section level. Is this practical?
>

I didn't quite understand this.

Also what are you thoughts on my idea of accomplishing function tracing
using CTF? Do you think its a viable approach? This is written in the
function tracing use case below:

+Requirements
+
+
+The current tracing framework provides this functionality with
:ref:`tracebuffering`. The output is
+provided in the form of printing on console or saving the buffer in the
form of a bin file. In order to
+develop this use case using CTF we need to be able to convert either the
bin file or console output to CTF.
+The saved bin file must also first be transported to the host from the
target for this purpose. On the other
+hand console output could be written to a text file which can then be
converted to CTF.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Adding tracing documentation in user manual

[Vidushi Vashishth]

Hi!

This is a rough skeleton of the tracing chapter in the user manual
documentation with some incomplete bits. I have covered the "to be
completed bits" in some of my blogs and that should not take much time to
finish. Let me know if you have suggestions.

Thanks!
Vidushi

On Tue, Jun 5, 2018 at 9:10 PM, Vidushi Vashishth 
wrote:

> ---
>  user/index.rst|  2 +
>  user/tracing/development.rst  | 12 ++
>  user/tracing/index.rst| 25 
>  user/tracing/introduction.rst | 90 ++
> +
>  user/tracing/usecases.rst | 77 
>  5 files changed, 206 insertions(+)
>  create mode 100644 user/tracing/development.rst
>  create mode 100644 user/tracing/index.rst
>  create mode 100644 user/tracing/introduction.rst
>  create mode 100644 user/tracing/usecases.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index 8cbcd1b..a764fe8 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/
> .
>
> tools/index
>
> +tracing/index
> +
> support/index
>
> glossary/index
> diff --git a/user/tracing/development.rst b/user/tracing/development.rst
> new file mode 100644
> index 000..ad74d8f
> --- /dev/null
> +++ b/user/tracing/development.rst
> @@ -0,0 +1,12 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _development:
> +
> +Tracing Development
> +***
> +
> +RTEMS trace is an open source project currently under development.
> +
> +This section can contain how to build the rtems-tools after making
> changes to the trace linker.
> diff --git a/user/tracing/index.rst b/user/tracing/index.rst
> new file mode 100644
> index 000..ad22439
> --- /dev/null
> +++ b/user/tracing/index.rst
> @@ -0,0 +1,25 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _tracing-framework:
> +
> +RTEMS Tracing Framework
> +***
> +.. index:: Tracing Framework
> +
> +RTEMS Tracing Framework is an on-target software based system which helps
> track
> +the ongoings inside applications, 3rd party packages and the kernel in
> real time.
> +
> +Software based tracing is a complex process which requires components on
> both the
> +target and the host to work together. However its portability across all
> architectures
> +and board support packages makes it a useful asset. A key requirement in
> RTEMS trace process
> +is to take existing code in compiled format (ELF) and instrument it in
> order to log various events
> +and records in real time. However instrumenting of the code for tracing
> should happen without rebuilding
> +the code from the source and without annotating the source with trace
> code.
> +
> +.. toctree::
> +
> +   introduction
> +   usecases
> +   development
> diff --git a/user/tracing/introduction.rst b/user/tracing/introduction.rst
> new file mode 100644
> index 000..3314447
> --- /dev/null
> +++ b/user/tracing/introduction.rst
> @@ -0,0 +1,90 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _introduction:
> +
> +Introduction to Tracing
> +***
> +
> +Tracing is an important function which has several applications including
> identification of
> +complex threading, detection of deadlocks, tracing functions along with
> their argument values,
> +and return values through progression of several function calls and audit
> the performance of an
> +application according to required specifications.
> +
> +RTEMS tracing framework is under development and welcomes contribution by
> users.
> +
> +RTEMS has the following trace components:
> +
> +- RTEMS Trace Linker
> +- Capture Engine
> +- Common Trace Format Integration
> +
> +.. note::
> +
> +I could create separate pages to explain the aforementioned
> components in detail.
> +
> +
> +RTEMS trace framework can currently function using the following methods:
> +
> +RTEMS Trace Using Trace Buffering
> +=
> +
> +To be completed
> +
> +RTEMS Trace Using Printk
> +
> +
> +To be completed
> +
> +RTEMS Trace Using CTF
> +=
> +
> +`Common Trace Format <http://diamon.org/ctf/>`_ is a binary trace format
> which is fast to write
> +and has great flexibility. It allows traces to be developed by bare-metal
> applications or by any
> +other 

[PATCH v3] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index af9fc31..c17f2f1 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -26,6 +26,8 @@ buffer-local = " uint8_t* in;"
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "
+header = "#include "
 
 [trace-buffer-tracers]
 code = <real_priority;
+  Thread_Control* tc = _Thread_Get_executing();
+  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
 }
 
 static inline uint32_t __rtld_tbg_executing_state(void)
-- 
2.7.4

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

[PATCH v2] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index ee68d55..c17f2f1 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -27,6 +27,7 @@ header = "#include "
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "
 
 [trace-buffer-tracers]
 code = <

Re: [PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index ee68d55..c17f2f1 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -27,6 +27,7 @@ header = "#include "
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "

 [trace-buffer-tracers]
 code = <<Real_priority.priority;
 }

-- 
2.7.4


On Wed, May 30, 2018 at 7:24 PM, Vidushi Vashishth 
wrote:

> >Based on this error, I believe you need to drop the "struct", given
> >that Thread_Control is the typedef for "struct _Thread_Control".
>
> Oh yes you are right. It was originally written with the "struct" so I
> somehow overlooked it. I tired it this way. It works thanks.
>
> >Minor, but in most other places in RTEMS, I've seen pointers declared
> >with the asterisk on the variable not on the type ("int *ptr;" instead
> >of "int* ptr;").
>
> The trace linker code was last updated couple of years ago and this isn't
> the convention used in it. I don't know if the convention has changed but I
> stuck with how it was done in the configuration files of the trace linker.
>
> On Wed, May 30, 2018 at 7:05 PM, Amaan Cheval 
> wrote:
>
>> On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth 
>> wrote:
>> > Could you please change the
>> >
>> > struct _Thread_Control
>> >
>> > to
>> >
>> > Thread_Control
>> >
>> > and check if it still works.
>> >
>> > In RTEMS, we use typedefs for structures in general.
>> >
>> > I tried to include the threadq.h header file so that I could use the
>> > variable Thread_Control instead of _Thread_Control. This header file
>> has the
>> > following typedef statement:
>> >
>> > typedef struct _Thread_Control Thread_Control;
>> >
>> > However this leads to the following error:
>> >
>> > fileio-wrapper.c:389:31: warning: initialization from incompatible
>> pointer
>> > type [-Wincompatible-pointer-types]
>> >struct Thread_Control* tc = _Thread_Get_executing();
>> >^
>>
>> Based on this error, I believe you need to drop the "struct", given
>> that Thread_Control is the typedef for "struct _Thread_Control".
>>
>> Minor, but in most other places in RTEMS, I've seen pointers declared
>> with the asterisk on the variable not on the type ("int *ptr;" instead
>> of "int* ptr;").
>>
>> > fileio-wrapper.c:390:32: warning: passing argument 1 of
>> > '_Thread_Get_priority' from incompatible pointer type
>> > [-Wincompatible-pointer-types]
>> >return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>> >
>> > I had tried this earlier too. So it doesn't work.
>> >
>> >
>> >
>> > On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber
>> >  wrote:
>> >>
>> >>
>> >>
>> >> On 29/05/18 17:36, Vidushi Vashishth wrote:
>> >>>
>> >>> ---
>> >>>   linkers/rtld-trace-buffer.ini | 5 +++--
>> >>>   1 file changed, 3 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/linkers/rtld-trace-buffer.ini
>> >>> b/linkers/rtld-trace-buffer.ini
>> >>> index af9fc31..ee68d55 100644
>> >>> --- a/linkers/rtld-trace-buffer.ini
>> >>> +++ b/linkers/rtld-trace-buffer.ini
>> >>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
>> >>>   header = "#include "
>> >>>   header = "#include "
>> >>>   header = "#include "
>> >>> +header = "#include "
>> >>> [trace-buffer-tracers]
>> >>>   code = <<> >>> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
>> >>>   static inline uint32_t __rtld_tbg_executing_status(void)
>> >>>   {
>> >>> /* @fixme Add the current CPU for SMP. */
>> >>> -  struct Thread_Control* tc = _Thread_Get_executing();
>> >>
>> >>
>> >> Could you please change the
>> >>
>> >> struct _Thread_Control
>> >>
>> >> to
>> >>
>> >> Thread_Control
>> >>
>> &

Re: [PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

>Based on this error, I believe you need to drop the "struct", given
>that Thread_Control is the typedef for "struct _Thread_Control".

Oh yes you are right. It was originally written with the "struct" so I
somehow overlooked it. I tired it this way. It works thanks.

>Minor, but in most other places in RTEMS, I've seen pointers declared
>with the asterisk on the variable not on the type ("int *ptr;" instead
>of "int* ptr;").

The trace linker code was last updated couple of years ago and this isn't
the convention used in it. I don't know if the convention has changed but I
stuck with how it was done in the configuration files of the trace linker.

On Wed, May 30, 2018 at 7:05 PM, Amaan Cheval 
wrote:

> On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth 
> wrote:
> > Could you please change the
> >
> > struct _Thread_Control
> >
> > to
> >
> > Thread_Control
> >
> > and check if it still works.
> >
> > In RTEMS, we use typedefs for structures in general.
> >
> > I tried to include the threadq.h header file so that I could use the
> > variable Thread_Control instead of _Thread_Control. This header file has
> the
> > following typedef statement:
> >
> > typedef struct _Thread_Control Thread_Control;
> >
> > However this leads to the following error:
> >
> > fileio-wrapper.c:389:31: warning: initialization from incompatible
> pointer
> > type [-Wincompatible-pointer-types]
> >struct Thread_Control* tc = _Thread_Get_executing();
> >^
>
> Based on this error, I believe you need to drop the "struct", given
> that Thread_Control is the typedef for "struct _Thread_Control".
>
> Minor, but in most other places in RTEMS, I've seen pointers declared
> with the asterisk on the variable not on the type ("int *ptr;" instead
> of "int* ptr;").
>
> > fileio-wrapper.c:390:32: warning: passing argument 1 of
> > '_Thread_Get_priority' from incompatible pointer type
> > [-Wincompatible-pointer-types]
> >return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
> >
> > I had tried this earlier too. So it doesn't work.
> >
> >
> >
> > On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber
> >  wrote:
> >>
> >>
> >>
> >> On 29/05/18 17:36, Vidushi Vashishth wrote:
> >>>
> >>> ---
> >>>   linkers/rtld-trace-buffer.ini | 5 +++--
> >>>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/linkers/rtld-trace-buffer.ini
> >>> b/linkers/rtld-trace-buffer.ini
> >>> index af9fc31..ee68d55 100644
> >>> --- a/linkers/rtld-trace-buffer.ini
> >>> +++ b/linkers/rtld-trace-buffer.ini
> >>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
> >>>   header = "#include "
> >>>   header = "#include "
> >>>   header = "#include "
> >>> +header = "#include "
> >>> [trace-buffer-tracers]
> >>>   code = << >>> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
> >>>   static inline uint32_t __rtld_tbg_executing_status(void)
> >>>   {
> >>> /* @fixme Add the current CPU for SMP. */
> >>> -  struct Thread_Control* tc = _Thread_Get_executing();
> >>
> >>
> >> Could you please change the
> >>
> >> struct _Thread_Control
> >>
> >> to
> >>
> >> Thread_Control
> >>
> >> and check if it still works.
> >>
> >> In RTEMS, we use typedefs for structures in general.
> >>
> >>> -  return (tc->current_priority << 8) | tc->real_priority;
> >>> +  struct _Thread_Control* tc = _Thread_Get_executing();
> >>> +  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
> >>>   }
> >>> static inline uint32_t __rtld_tbg_executing_state(void)
> >>
> >>
> >> --
> >> 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
> >
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

Could you please change the

struct _Thread_Control

to

Thread_Control

and check if it still works.

In RTEMS, we use typedefs for structures in general.

I tried to include the threadq.h header file so that I could use the
variable Thread_Control instead of _Thread_Control. This header file has
the following typedef statement:

*typedef struct _Thread_Control Thread_Control;*

However this leads to the following error:







*fileio-wrapper.c:389:31: warning: initialization from incompatible pointer
type [-Wincompatible-pointer-types]   struct Thread_Control* tc =
_Thread_Get_executing();
^fileio-wrapper.c:390:32: warning: passing argument 1
of '_Thread_Get_priority' from incompatible pointer type
[-Wincompatible-pointer-types]   return (_Thread_Get_priority(tc) << 8) |
tc->Real_priority.priority;*
I had tried this earlier too. So it doesn't work.



On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 29/05/18 17:36, Vidushi Vashishth wrote:
>
>> ---
>>   linkers/rtld-trace-buffer.ini | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.in
>> i
>> index af9fc31..ee68d55 100644
>> --- a/linkers/rtld-trace-buffer.ini
>> +++ b/linkers/rtld-trace-buffer.ini
>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
>>   header = "#include "
>>   header = "#include "
>>   header = "#include "
>> +header = "#include "
>> [trace-buffer-tracers]
>>   code = <<> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
>>   static inline uint32_t __rtld_tbg_executing_status(void)
>>   {
>> /* @fixme Add the current CPU for SMP. */
>> -  struct Thread_Control* tc = _Thread_Get_executing();
>>
>
> Could you please change the
>
> struct _Thread_Control
>
> to
>
> Thread_Control
>
> and check if it still works.
>
> In RTEMS, we use typedefs for structures in general.
>
> -  return (tc->current_priority << 8) | tc->real_priority;
>> +  struct _Thread_Control* tc = _Thread_Get_executing();
>> +  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>>   }
>> static inline uint32_t __rtld_tbg_executing_state(void)
>>
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] CTF generator configuration files

[Vidushi Vashishth]

Thats alright no problem! I will begin work on the documentation.



On Wed, May 30, 2018 at 4:59 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/05/18 13:27, Vidushi Vashishth wrote:
>
>> Hi Sebastian!
>>
>> Yes I have been working on the documentation. I wrote a blog about the
>> the tracing framework use cases a while ago. It can be seen here
>> https://vidushivashishth.github.io/Third-post-copy/
>> I will write a blog about trace buffer generation which would explain all
>> the questions you have posed too. As suggested by Gedare the blog posts
>> will somewhat be the first draft of what is to go in the user manual. I
>> would appreciate your feedback on the blogpost.
>>
>
> I would highly appreciate if you do this not in a blog. The primary medium
> for RTEMS development is this mailing list. Please start with a skeleton
> structure for this new stuff in the user manual and send patches to the
> mailing list for review.
>
>
> --
> 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] CTF generator configuration files

[Vidushi Vashishth]

Hi Sebastian!

Yes I have been working on the documentation. I wrote a blog about the the
tracing framework use cases a while ago. It can be seen here
https://vidushivashishth.github.io/Third-post-copy/
I will write a blog about trace buffer generation which would explain all
the questions you have posed too. As suggested by Gedare the blog posts
will somewhat be the first draft of what is to go in the user manual. I
would appreciate your feedback on the blogpost.

Thanks!

On Wed, May 30, 2018 at 11:03 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> could you please also work on the user documentation and the use cases. I
> am not an expert in this CTF stuff. Without an introduction in the user
> manual I am pretty helpless. I don't know which tools I have to install. I
> don't know the workflow. I don't know why I need a "CTF generator
> configuration file". I have no time to read all the documents here and
> there. Users have no time and are impatient.
>
> --
> 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

[GSOC] CTF generator configuration files

[Vidushi Vashishth]

Hello!

I am in the process of writing a CTF generator configuration file. This
will be used in converting trace data into Common Trace Format. I am
following the flow of events as described in [1] for the conversion
process. Have there been previous attempts to create CTF generator
configuration? Is there any change to the CTF conversion process? The wiki
page I am referring to for this purpose was last updated in 2016 hence I
needed to ask this. I have followed the documentation provided in [2] and
[3] to understand how configuration files are written and function. Have I
left any relevant documentation which could help in this process?

Best,
Vidushi

References:
[1] https://devel.rtems.org/wiki/Developer/Tracing
[2] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
[3] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] Tracing

[Vidushi Vashishth]

Hi!

Just updating that I have sent a patch which fixes the trace buffer
generation. I am now able to generate trace buffers for the fileio sample
testcase. I will begin work on CTF conversion now.

Thanks,
Vidushi

On Tue, May 29, 2018 at 1:00 PM, Vidushi Vashishth 
wrote:

> Hey Sebastian!
>
> Yes I have been working on the trace linker the past week. It is outdated
> and needs improvements. A lot of my work depends on me fixing the trace
> linker. I had informed about this last week during the meeting. I thought I
> would update you as soon as I make progress. Nevertheless the following is
> the status of my work:
>
> 1) Identified problems with the trace linker and working on a patch which
> would fix the trace buffer generation. Using the fileio sample as a
> testcase. I talked to Chris regarding the problems I was facing in the
> process yesterday and am getting close to finishing it.
>
> 2) Collected all the relevant wiki documentation page links about the
> tracing system which would be removed once the user manual is updated.
>
> 3) Installed babeltrace on mac and linux environments and understood its
> working. Once the trace linker is fixed and starts generating trace data it
> would be fed into babeltrace to convert it into CTF.
>
> That's about it.
>
> Best,
> Vidushi
>
> On Tue, May 29, 2018 at 12:37 PM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Vidushi,
>>
>> I though you agreed to send a regular status report on Monday? Do you
>> still work on the project?
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> <https://maps.google.com/?q=Dornierstr.+4,+D-82178+Puchheim,+Germany=gmail=g>
>> 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

[PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index af9fc31..ee68d55 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "
 
 [trace-buffer-tracers]
 code = <real_priority;
+  struct _Thread_Control* tc = _Thread_Get_executing();
+  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
 }
 
 static inline uint32_t __rtld_tbg_executing_state(void)
-- 
2.7.4

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

Re: [GSoC] Tracing

[Vidushi Vashishth]

Hey Sebastian!

Yes I have been working on the trace linker the past week. It is outdated
and needs improvements. A lot of my work depends on me fixing the trace
linker. I had informed about this last week during the meeting. I thought I
would update you as soon as I make progress. Nevertheless the following is
the status of my work:

1) Identified problems with the trace linker and working on a patch which
would fix the trace buffer generation. Using the fileio sample as a
testcase. I talked to Chris regarding the problems I was facing in the
process yesterday and am getting close to finishing it.

2) Collected all the relevant wiki documentation page links about the
tracing system which would be removed once the user manual is updated.

3) Installed babeltrace on mac and linux environments and understood its
working. Once the trace linker is fixed and starts generating trace data it
would be fed into babeltrace to convert it into CTF.

That's about it.

Best,
Vidushi

On Tue, May 29, 2018 at 12:37 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> I though you agreed to send a regular status report on Monday? Do you
> still work on the project?
>
> --
> 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] Weekly report

[Vidushi Vashishth]

Hey!

I did take note of some. I think it should not take too much time to
document these. I will surely do this after I am done with running my CTF
conversion formula on the linux system.

Best,
Vidushi

On Tue, May 22, 2018 at 3:23 PM, Chris Johns <chr...@rtems.org> wrote:

> On 22/5/18 1:48 am, Vidushi Vashishth wrote:
> >
> > I was facing a lot of problems trying to get everything running on MacOS.
> > Babeltrace in particular had a lot of dependencies and it became
> exceedingly
> > difficult to build it.
>
> Are you able to document the dependencies you found? A post to this list is
> fine. It would be nice to not to have start that work again.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] Weekly report

[Vidushi Vashishth]

Hey!

I was facing a lot of problems trying to get everything running on MacOS.
Babeltrace in particular had a lot of dependencies and it became
exceedingly difficult to build it. So after Gedare's suggestion during the
weekly meeting, I switched to Ubuntu on my old laptop. The process took a
lot of time hence I couldn't accomplish all of my tasks. I did however
accomplish 1) and some bits of 4). Here is the link of my blog discussing
the use cases you asked for:
https://vidushivashishth.github.io/Third-post-copy/ . Let me know if you
have suggestions about the use cases.

I setup everything including ubuntu 16.04 to rtems sparc-erc32 architecture
again on the new machine. I have an idea of what needs to be done to setup
CTF conversion. I hope to deliver something concrete in another day's time.
I hope that's okay. I however, have learnt to build stuff quicker now.



On Mon, May 21, 2018 at 4:04 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> do you already have something that we can try out?
>
> ----- Vidushi Vashishth <reachv...@gmail.com> schrieb:
> > Hi!
> >
> > As asked by my mentor, I am going to post my weekly project target on the
> > mailing list every Monday. For this week I have the following planned:
> >
> > 1) Develop use cases (common development problems catered to, etc) for
> the
> > rtems tracing support and identify what all needs to be implemented
> around
> > with it. This would be documented first in my blog then the users manual.
> >
> > 2) Create a babeltrace conversion formula for CTF conversion. Document it
> > with sufficient example test cases.
> >
> > 3) Fixing the buffering sample test cases which is currently failing a
> > rtems-path check on execution.
> >
> > 4) Gain familiarity with barectf, identify methods of integrating it with
> > rtems-tld output and working on array support for barectf.
> >
> >
> > Best,
> > Vidushi
>
> --
> 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.huber at embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] Weekly report

[Vidushi Vashishth]

Oh okay, will keep that in mind from the next time!

On Tue, May 15, 2018 at 6:31 PM, Gedare Bloom <ged...@rtems.org> wrote:

> Minor nit: please put a short description of your project in the title
> (e.g., "tracing") just to avoid overly plain and possibly confusing
> titles if multiple students start to do this. Thanks for the update!
>
> On Mon, May 14, 2018 at 9:12 PM, Vidushi Vashishth <reachv...@gmail.com>
> wrote:
> > Hi!
> >
> > As asked by my mentor, I am going to post my weekly project target on the
> > mailing list every Monday. For this week I have the following planned:
> >
> > 1) Develop use cases (common development problems catered to, etc) for
> the
> > rtems tracing support and identify what all needs to be implemented
> around
> > with it. This would be documented first in my blog then the users manual.
> >
> > 2) Create a babeltrace conversion formula for CTF conversion. Document it
> > with sufficient example test cases.
> >
> > 3) Fixing the buffering sample test cases which is currently failing a
> > rtems-path check on execution.
> >
> > 4) Gain familiarity with barectf, identify methods of integrating it with
> > rtems-tld output and working on array support for barectf.
> >
> >
> > Best,
> > Vidushi
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[GSOC] Weekly report

[Vidushi Vashishth]

Hi!

As asked by my mentor, I am going to post my weekly project target on the
mailing list every Monday. For this week I have the following planned:

1) Develop use cases (common development problems catered to, etc) for the
rtems tracing support and identify what all needs to be implemented around
with it. This would be documented first in my blog then the users manual.

2) Create a babeltrace conversion formula for CTF conversion. Document it
with sufficient example test cases.

3) Fixing the buffering sample test cases which is currently failing a
rtems-path check on execution.

4) Gain familiarity with barectf, identify methods of integrating it with
rtems-tld output and working on array support for barectf.


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

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

hi!

> I think we should define some basic functionality which should be
available ready to use during mid term evaluation. I want to avoid a last
minute delivery during the project end with no time to fix problems after a
review. This likely results in some half-finished work which nobody can use.

Currently I plan to deliver a barectf integrated RTEMS trace linker and a
transport mechanism to deliver trace data to the host machine using TCP by
mid term evaluation (second phase). I intend to fix any errors encountered
in the process by end of second phase itself. I understand how kernel level
tracing will be beneficial to the tracing framework. I can modify my
proposal to include this as one of my goals. I also intend to deliver live
tracing functionality as a goal of my third phase. Would it be viable to
accommodate kernel level tracing to my current plan? Or should I discount
any of my current goals (integration of barectf, transport mechanism to
host, live tracing) in place of it?

Regards,
Vidushi Vashishth

On Mon, Mar 26, 2018 at 12:17 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/03/18 16:28, Gedare Bloom wrote:
>
>> Hello Vidushi, Sebastian:
>>
>> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>> <sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello Vidushi,
>>>
>>> the RTEMS Trace Linker is definitely an interesting tool to track down
>>> difficult and specific issues. However, this is a nice to have optional
>>>
>> out-of-box Trace Linker with integration to debugger or CTF tools will
>> be highly beneficial for the "user-side" experience of RTEMS. This can
>> be quite beneficial for marketing if nothing else. :) Given the
>> current state, and that we've had a few projects already on this
>> topic, any project working here needs to focus on delivering a
>> complete slice of the software stack from trace configuration all the
>> way through trace output analysis. There is a lot to review to get the
>> plan right here. I've made comments on the google doc proposal.
>>
>
> I think we should define some basic functionality which should be
> available ready to use during mid term evaluation. I want to avoid a last
> minute delivery during the project end with no time to fix problems after a
> review. This likely results in some half-finished work which nobody can use.
>
>
>> feature from my point of view. We should focus on basic functionality and
>>> this is interrupt entry/exit and thread switching. This should work out
>>> of
>>> the box without having to compile RTEMS with specialized configuration
>>>
>> I agree that this is also an important aspect for "kernel-level"
>> tracing, and it should be implemented directly into RTEMS with
>> standard configuration (configure or confdefs.h options). The
>> requirements for this functionality is unclear, though, such as what
>> the trace output should be.
>>
>> options. It should work via a serial line and network (UDP I guess). It
>>>
>> I don't see how network support can exist out-of-the-box unless the
>> solution exists at libbsd level. I think there will be two pieces to
>> this kind of project:
>> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
>> 2. transporting buffers via worker threads.
>>
>> Then, one can implement a basic worker thread using available drivers
>> in rtems, and also more advanced (network) workers relying on libbsd.
>>
>
> The network transport should rely on the POSIX sockets API only as defined
> by Newlib.
>
>
>> should also support SMP machines. This requires per-processor trace
>>> buffers.
>>> The trace buffer should work without locks, e.g. only interrupt
>>> disable/enable. I would do also a short review of existing trace
>>> solutions.
>>>
>> The use of per-processor buffers makes the "reader" side (transport)
>> more complicated. This is a good place to consider a wait-free
>> non-blocking data structure, or a rwlock with writer prioritization.
>> At any rate, a good design is needed here with some careful thought.
>>
>
> Everything which uses an atomic read-modify-write operation on some global
> data will lead to a significant change in the overall timing on larger
> machines with several cache layers (e.g. QoriIQ T4240). The reader side
> with per-processor data is not that difficult if everything runs in
> kernel-space. You can use processor affine threads (supported by the
> default SMP scheduler) or inter-processor interrupts to fetch the data.
>
&

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hi!

I have uploaded my final proposal pdf for GSOC'18. I have tried to
incorporate all the comments made. PFA the final draft of the proposal.

Thanks for being such a wonderful community! I enjoyed every bit of the
application process.

Warm regards,
Vidushi Vashishth

​
 GSOC_proposal_Vidushi_runtime_tracing
<https://docs.google.com/document/d/1M7IUGsK3J6zqsNmyDhWKuRT69m4_SWqjftczrJKgHPM/edit?usp=drive_web>
​

On Sat, Mar 24, 2018 at 1:23 AM, Vidushi Vashishth <reachv...@gmail.com>
wrote:

> Hello!
>
> >>We should focus on basic functionality and this is interrupt entry/exit
> and thread switching. This should work out of the box without having to
> compile RTEMS with specialized configuration options. It should work via a
> serial line and network (UDP I guess). It should also support SMP machines.
> This requires per-processor trace buffers. The trace buffer should work
> without locks, e.g. only interrupt disable/enable. I would do also a short
> review of existing trace solutions. Maybe we don't have to re-invent the
> wheel. For example:
>
> http://www.cs.unc.edu/~bbb/feathertrace/
>
> I see. I went through the feathertrace solution documentation. I am also
> looking at other solutions, including Linux Trace Toolkit. I will reinvent
> the focus of my proposal to include the basic functionality suggested.
>
> >There is a lot to review to get the
> plan right here. I've made comments on the google doc proposal.
>
> Yes. I went over the comments. Thank you for such a detailed explanation.
> I will amend the proposal to incorporate the comments.
>
> >I don't see how network support can exist out-of-the-box unless the
> solution exists at libbsd level. I think there will be two pieces to
> this kind of project:
> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
> 2. transporting buffers via worker threads.
>
> Then, one can implement a basic worker thread using available drivers
> in rtems, and also more advanced (network) workers relying on libbsd.
>
> >The use of per-processor buffers makes the "reader" side (transport)
> more complicated. This is a good place to consider a wait-free
> non-blocking data structure, or a rwlock with writer prioritization.
> At any rate, a good design is needed here with some careful thought.
>
> I will investigate if an out of the box solution exists at the libbsd
> level and post it here.
>
>
> Regards,
> Vidushi
>
>
>
> On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom <ged...@rtems.org> wrote:
>
>> Hello Vidushi, Sebastian:
>>
>> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>> <sebastian.hu...@embedded-brains.de> wrote:
>> > Hello Vidushi,
>> >
>> > the RTEMS Trace Linker is definitely an interesting tool to track down
>> > difficult and specific issues. However, this is a nice to have optional
>>
>> out-of-box Trace Linker with integration to debugger or CTF tools will
>> be highly beneficial for the "user-side" experience of RTEMS. This can
>> be quite beneficial for marketing if nothing else. :) Given the
>> current state, and that we've had a few projects already on this
>> topic, any project working here needs to focus on delivering a
>> complete slice of the software stack from trace configuration all the
>> way through trace output analysis. There is a lot to review to get the
>> plan right here. I've made comments on the google doc proposal.
>>
>> > feature from my point of view. We should focus on basic functionality
>> and
>> > this is interrupt entry/exit and thread switching. This should work out
>> of
>> > the box without having to compile RTEMS with specialized configuration
>>
>> I agree that this is also an important aspect for "kernel-level"
>> tracing, and it should be implemented directly into RTEMS with
>> standard configuration (configure or confdefs.h options). The
>> requirements for this functionality is unclear, though, such as what
>> the trace output should be.
>>
>> > options. It should work via a serial line and network (UDP I guess). It
>>
>> I don't see how network support can exist out-of-the-box unless the
>> solution exists at libbsd level. I think there will be two pieces to
>> this kind of project:
>> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
>> 2. transporting buffers via worker threads.
>>
>> Then, one can implement a basic worker thread using available drivers
>> in rtems, and also more advanced (network) workers relying on libbsd.
>>
>> > should also support SMP machines.

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hello!

>>We should focus on basic functionality and this is interrupt entry/exit
and thread switching. This should work out of the box without having to
compile RTEMS with specialized configuration options. It should work via a
serial line and network (UDP I guess). It should also support SMP machines.
This requires per-processor trace buffers. The trace buffer should work
without locks, e.g. only interrupt disable/enable. I would do also a short
review of existing trace solutions. Maybe we don't have to re-invent the
wheel. For example:

http://www.cs.unc.edu/~bbb/feathertrace/

I see. I went through the feathertrace solution documentation. I am also
looking at other solutions, including Linux Trace Toolkit. I will reinvent
the focus of my proposal to include the basic functionality suggested.

>There is a lot to review to get the
plan right here. I've made comments on the google doc proposal.

Yes. I went over the comments. Thank you for such a detailed explanation. I
will amend the proposal to incorporate the comments.

>I don't see how network support can exist out-of-the-box unless the
solution exists at libbsd level. I think there will be two pieces to
this kind of project:
1. capturing traces to memory buffers from interrupt/"kernel" contexts.
2. transporting buffers via worker threads.

Then, one can implement a basic worker thread using available drivers
in rtems, and also more advanced (network) workers relying on libbsd.

>The use of per-processor buffers makes the "reader" side (transport)
more complicated. This is a good place to consider a wait-free
non-blocking data structure, or a rwlock with writer prioritization.
At any rate, a good design is needed here with some careful thought.

I will investigate if an out of the box solution exists at the libbsd level
and post it here.


Regards,
Vidushi



On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom  wrote:

> Hello Vidushi, Sebastian:
>
> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>  wrote:
> > Hello Vidushi,
> >
> > the RTEMS Trace Linker is definitely an interesting tool to track down
> > difficult and specific issues. However, this is a nice to have optional
>
> out-of-box Trace Linker with integration to debugger or CTF tools will
> be highly beneficial for the "user-side" experience of RTEMS. This can
> be quite beneficial for marketing if nothing else. :) Given the
> current state, and that we've had a few projects already on this
> topic, any project working here needs to focus on delivering a
> complete slice of the software stack from trace configuration all the
> way through trace output analysis. There is a lot to review to get the
> plan right here. I've made comments on the google doc proposal.
>
> > feature from my point of view. We should focus on basic functionality and
> > this is interrupt entry/exit and thread switching. This should work out
> of
> > the box without having to compile RTEMS with specialized configuration
>
> I agree that this is also an important aspect for "kernel-level"
> tracing, and it should be implemented directly into RTEMS with
> standard configuration (configure or confdefs.h options). The
> requirements for this functionality is unclear, though, such as what
> the trace output should be.
>
> > options. It should work via a serial line and network (UDP I guess). It
>
> I don't see how network support can exist out-of-the-box unless the
> solution exists at libbsd level. I think there will be two pieces to
> this kind of project:
> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
> 2. transporting buffers via worker threads.
>
> Then, one can implement a basic worker thread using available drivers
> in rtems, and also more advanced (network) workers relying on libbsd.
>
> > should also support SMP machines. This requires per-processor trace
> buffers.
> > The trace buffer should work without locks, e.g. only interrupt
> > disable/enable. I would do also a short review of existing trace
> solutions.
>
> The use of per-processor buffers makes the "reader" side (transport)
> more complicated. This is a good place to consider a wait-free
> non-blocking data structure, or a rwlock with writer prioritization.
> At any rate, a good design is needed here with some careful thought.
>
> > Maybe we don't have to re-invent the wheel. For example:
> >
> > http://www.cs.unc.edu/~bbb/feathertrace/
> >
> > --
> > 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
>

GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hi!

I apologise for the delay in submission. Was caught up with college project
submission.

PFA my proposal application for GSOC'18. I would appreciate insight and
suggestions.

Best,
Vidushi Vashishth

​
 GSOC_proposal_Vidushi_runtime_tracing
<https://docs.google.com/document/d/1M7IUGsK3J6zqsNmyDhWKuRT69m4_SWqjftczrJKgHPM/edit?usp=drive_web>
​
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error in Trace-buffering example

[Vidushi Vashishth]

>> The -B option should have a full path not a partial one. The $prefix
used when
>> building the BSP is missing.
>>
> >Did you use a full path? Is there an argument missing to the invocation?
>>

Adding full path to the -B option works. Turns out $prefix is not required
in the command.

>The link provided to our wiki does not have the full path. I am not sure
why ...

The wiki description also does not show the full path for fileio.exe and
init.o. I made changes to the command to overcome the errors. Should I
raise a ticket to make the changes?


However now on trying to run the trace link command (which follows) I am
encountering an error:

Command:

rtems-tld -C fileio-trace.ini -W fileio-wrapper --
-B/Users/vidushi/development/rtems/5/sparc-rtems5/erc32/lib/ -specs
bsp_specs -qrtems -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections
-Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress -o
sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o

Error:

error: /Users/vidushi/development/rtems/kernel/erc32: Invalid RTEMS path

According to the wiki documentation the rtems-path in the configuration
file should be set to the installed BSP.


Following is the [fileio-options] section of my configuration file:


;--

[fileio-options]

dump-on-error = true

;

; Tools

;

prefix = /Users/vidushi/development/rtems/5

rtems-path = /Users/vidushi/development/rtems/kernel/erc32

rtems-bsp = sparc/erc32

;

; Generator options.

;

gen-enables = enable

gen-triggers = enable


;--


My rtems-path does point to the installed BSP directory. I can't think of a
reason for this error.



On an unrelated note I am working on my proposal and would try to submit it
by end of today. For the past couple of days I have been trying to make the
trace-buffering example work and am hoping to solve the #2780 ticket. I
have also been going through the work of previous GSOC interns in the same
project trying to ascertain if I can carry forward from where they left
off. Hence I wanted to ask if trying to implement the live-tracing
functionality over several transport mechanisms would be a viable goal for
the proposal? Assuming it wasn't finished.



Also, given the paucity of time would you suggest that I finish the
proposal first or my patch for the aforementioned ticket.


References:

#2780 : https://devel.rtems.org/ticket/2780


Best,

Vidushi




On Mon, Mar 19, 2018 at 11:20 AM, Chris Johns <chr...@rtems.org> wrote:

> On 19/03/2018 03:44, Joel Sherrill wrote:
> > On Mar 18, 2018 6:48 AM, "Vidushi Vashishth" <reachv...@gmail.com
> > <mailto:reachv...@gmail.com>> wrote:
> >
> > Hello!
> >
> > I am hoping to apply to Gsoc'18 for the runtime tracing project. I am
> > following the RTEMS tracing documentation [1] and have been trying
> to run
> > the fileio trace sample to familiarise with how traces are
> generated. I have
> > set the rtems-path to the installed BSP erc32 in the
> fileio-trace.ini. The
> > directory structure of my set up is the same as provided in the User
> manual.
> > However while trying to link the fileio.exe I get a few errors:
> >
> > Command:
> >
> > sparc-rtems5-gcc -Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems \
> >
> >   -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections
> -Wall \
> >
> >   -Wmissing-prototypes -Wimplicit-function-declaration
> > -Wstrict-prototypes \
> >
> >   -Wnested-externs -Wl,--gc-sections -mcpu=cypress \
> >
> >   -o sparc-rtems5/c/erc32/testsuites/samples/fileio/
> fileio.exe
> > sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o
> >
> >
> > The -B option should have a full path not a partial one. The $prefix
> used when
> > building the BSP is missing.
> >
> > Did you use a full path? Is there an argument missing to the invocation?
> >
>
> The link provided to our wiki does not have the full path. I am not sure
> why ...
>
> > References:
> > [1] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
> > <https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering>
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Error in Trace-buffering example

[Vidushi Vashishth]

Hello!

I am hoping to apply to Gsoc'18 for the runtime tracing project. I am
following the RTEMS tracing documentation [1] and have been trying to run
the fileio trace sample to familiarise with how traces are generated. I
have set the rtems-path to the installed BSP erc32 in the fileio-trace.ini.
The directory structure of my set up is the same as provided in the User
manual. However while trying to link the fileio.exe I get a few errors:

Command:

sparc-rtems5-gcc -Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems \

  -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall \

  -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes \

  -Wnested-externs -Wl,--gc-sections -mcpu=cypress \

  -o sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o

Error:
 *sparc-rtems5-gcc:* *error: *bsp_specs: No such file or director


Command:

rtems-tld -C fileio-trace.ini -W fileio-wrapper --
-Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems -mcpu=cypress -O2 -g
-ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-Wl,--gc-sections -mcpu=cypress -o
sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o

Error:

error: /development/rtems/kernel/erc32: Invalid RTEMS path

I am in quite a fix. My directory structure seems okay. Would appreciate
some insight.


References:
[1] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering

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

Re: RSB build failure

[Vidushi Vashishth]

>Interesting. Please raise a ticket, set the component to rsb and assign to
me. I
will take a look next week. I cannot remember if I deleted the source
tarball on
MacOS and tested this.

Done. The ticket is #3355

Best,
Vidushi

On Sun, Mar 18, 2018 at 9:07 AM, Chris Johns <chr...@rtems.org> wrote:

> On 18/3/18 2:31 pm, Vidushi Vashishth wrote:
> >>I have been testing on a range of MacOS versions over the years and I
> have not
> > seen any issues report. If you have seen issues or you know of reports
> please
> > let me know.
> >
> > I was able to setup the environment successfully yesterday. Though in the
> > process I had another error which I managed to deal with. PFA the
> attached
> > report. Its about the relocation of the libexpat to github. I manually
> > downloaded the tar file and put it in the required sources folder.
> >
>
> Interesting. Please raise a ticket, set the component to rsb and assign to
> me. I
> will take a look next week. I cannot remember if I deleted the source
> tarball on
> MacOS and tested this.
>
> >>I have XCode installed with the command line package.
> >
> > I also have this. I had python packages installed using homebrew too
> which
> > weren't in the PATH variable. Adding them to the path solved the issue.
> >
>
> Thanks for reporting this. That clears up what was happening.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB build failure

[Vidushi Vashishth]

>I have been testing on a range of MacOS versions over the years and I have
not
seen any issues report. If you have seen issues or you know of reports
please
let me know.

I was able to setup the environment successfully yesterday. Though in the
process I had another error which I managed to deal with. PFA the attached
report. Its about the relocation of the libexpat to github. I manually
downloaded the tar file and put it in the required sources folder.

>I have XCode installed with the command line package.

I also have this. I had python packages installed using homebrew too which
weren't in the PATH variable. Adding them to the path solved the issue.



On Sun, Mar 18, 2018 at 8:41 AM, Chris Johns  wrote:

> On 17/3/18 9:00 pm, Amaan Cheval wrote:
> >> checking for python...
> > /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> >> checking for python2.7... no
> >> configure: error: python is missing or unusable
> >
> > That looks like the problem (at least on the surface). macOS does come
> with
> > Python built-in, but I don't believe that's good enough for development
>
> The default Python is fine for use with GDB and the RSB. There is no
> problem
> with the default provided by Apple on MacOS.
>
> $ uname -a
> Darwin huia 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST
> 2017;
> root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
> $ type python
> python is /usr/bin/python
> $ python --version
> Python 2.7.10
> $ python
> Python 2.7.10 (default, Jul 15 2017, 17:16:57)
> [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ^D
>
> Finally this a recent build result on a Mac Mini I have set up to check
> RTEMS
> builds:
>
> https://lists.rtems.org/pipermail/build/2018-February/000521.html
>
> I have XCode installed with the command line package.
>
> > (vague memories only of issues)
>
> I have been testing on a range of MacOS versions over the years and I have
> not
> seen any issues report. If you have seen issues or you know of reports
> please
> let me know.
>
> > - have you installed Python separately too?
>
> If yo do this or you are using homebrew, mscports or something else then
> you may
> have issues and you will need to look for support with those packaging
> projects.
>
> I do not have any packages from homebrew or macports so we know the RSB is
> working.
>
> Chris
>
RTEMS Tools Project - Source Builder Error Report
 Build: error: downloading 
https://github.com/libexpat/libexpat/releases/download/R_2_1_0/expat-2.1.0.tar.gz:
 all paths have failed, giving up
 Command Line: ../source-builder/sb-set-builder 
--prefix=/Users/vidushi/development/rtems/5 5/rtems-sparc
 Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) [GCC 4.2.1 (Apple 
Inc. build 5666) (dot 3)]
 
git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
 Darwin Vidushis-MacBook-Air.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan 
11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64
Tail of the build log:
x automake-1.12.6/t/libobj4.sh
x automake-1.12.6/t/check4-w.sh
x automake-1.12.6/t/libtoo10.sh
x automake-1.12.6/t/pr72.sh
x automake-1.12.6/t/dejagnu6.sh
x automake-1.12.6/t/override-html.sh
x automake-1.12.6/t/check-tests-in-builddir.sh
x automake-1.12.6/t/am-missing-prog.sh
x automake-1.12.6/t/aclocal7.sh
x automake-1.12.6/t/cygnus-no-installinfo.sh
x automake-1.12.6/t/pr266.sh
x automake-1.12.6/t/auxdir8.sh
x automake-1.12.6/t/self-check-is_newest.tap
x automake-1.12.6/t/cygnus-dependency-tracking.sh
x automake-1.12.6/t/parallel-tests-interrupt.tap
x automake-1.12.6/t/badline.sh
x automake-1.12.6/t/ar3.sh
x automake-1.12.6/t/location.sh
x automake-1.12.6/t/substtarg.sh
x automake-1.12.6/t/instsh3.sh
x automake-1.12.6/automake.in
x automake-1.12.6/doc/
x automake-1.12.6/doc/amhello/
x automake-1.12.6/doc/amhello/Makefile.am
x automake-1.12.6/doc/amhello/README
x automake-1.12.6/doc/amhello/src/
x automake-1.12.6/doc/amhello/src/Makefile.am
x automake-1.12.6/doc/amhello/src/main.c
x automake-1.12.6/doc/amhello/configure.ac
x automake-1.12.6/doc/automake.info-2
x automake-1.12.6/doc/automake.info
x automake-1.12.6/doc/amhello-1.0.tar.gz
x automake-1.12.6/doc/automake.info-3
x automake-1.12.6/doc/automake-history.info
x automake-1.12.6/doc/fdl.texi
x automake-1.12.6/doc/automake.info-1
x automake-1.12.6/doc/automake.texi
x automake-1.12.6/doc/automake-history.texi
x automake-1.12.6/doc/version.texi
x automake-1.12.6/doc/stamp-vti
x automake-1.12.6/doc/help2man
x automake-1.12.6/aclocal.m4
x automake-1.12.6/NEWS
+ cd automake-1.12.6
+ /bin/chmod -R a+rX,g-w,o-w .
+ /bin/cat 
/Users/vidushi/development/rtems/rsb/rtems/patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff
+ /usr/bin/patch -p1
patching file automake.in
+ cd 
/Users/vidushi/development/rtems/rsb/rtems/build/automake-1.12.6-x86_64-apple-darwin16.7.0-1
+ SB_CXC=no
==> clean 

Re: RSB build failure

[Vidushi Vashishth]

So it was a problem with the path variable.

Fixed it. The setup worked. Thanks!

On Sat, Mar 17, 2018 at 3:33 PM, Aditya Upadhyay <aadit0...@gmail.com>
wrote:

> install python-dev... Will solve the issue. If you are using ubuntu..
> sudo apt-get install python-dev.
>
> On Sat, Mar 17, 2018, 3:30 PM Amaan Cheval <amaan.che...@gmail.com> wrote:
>
>> Hi!
>>
>> > checking for python...
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
>> > checking for python2.7... no
>> > configure: error: python is missing or unusable
>>
>> That looks like the problem (at least on the surface). macOS does come
>> with
>> Python built-in, but I don't believe that's good enough for development
>> (vague memories only of issues) - have you installed Python separately
>> too?
>>
>> If so, could you confirm that you have the python2.7 binary in your PATH
>> variable too?
>>
>> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth <reachv...@gmail.com>
>> wrote:
>>
>> > Hello!
>>
>> > I was trying to set up the sparc/erc32 bsp on a new system and was
>> following the quickstart on the user manual. Though I have successfully
>> done this before, this time its throwing an error. PFA the rsb log file
>> with the error report. I was doing this to run the trace buffering
>> examples.
>>
>> > Why is the shell command /bin/sh -ex failing?
>>
>> > Regards,
>> > Vidushi
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RSB build failure

[Vidushi Vashishth]

Hello!

I was trying to set up the sparc/erc32 bsp on a new system and was
following the quickstart on the user manual. Though I have successfully
done this before, this time its throwing an error. PFA the rsb log file
with the error report. I was doing this to run the trace buffering
examples.

Why is the shell command /bin/sh -ex failing?

Regards,
Vidushi
RTEMS Tools Project - Source Builder Error Report
 Build: error: building sparc-rtems5-gdb-8.0.1-x86_64-apple-darwin16.7.0-1
 Command Line: ../source-builder/sb-set-builder 
--prefix=/Users/vidushi/development/rtems/5 5/rtems-sparc
 Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) [GCC 4.2.1 (Apple 
Inc. build 5666) (dot 3)]
 
git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
 Darwin Vidushis-MacBook-Air.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan 
11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64
Tail of the build log:
checking whether rawmemchr is declared without a macro... no
checking whether stpcpy is declared without a macro... yes
checking whether stpncpy is declared without a macro... yes
checking whether strchrnul is declared without a macro... no
checking whether strdup is declared without a macro... yes
checking whether strncat is declared without a macro... yes
checking whether strndup is declared without a macro... yes
checking whether strnlen is declared without a macro... yes
checking whether strpbrk is declared without a macro... yes
checking whether strsep is declared without a macro... yes
checking whether strcasestr is declared without a macro... yes
checking whether strtok_r is declared without a macro... yes
checking whether strerror_r is declared without a macro... yes
checking whether strsignal is declared without a macro... yes
checking whether strverscmp is declared without a macro... no
checking whether strstr works... yes
checking whether strtok_r is declared... (cached) yes
checking whether stat file-mode macros are broken... no
checking for mode_t... yes
checking for a thread-safe mkdir -p... 
../../../gdb-8.0.1/gdb/gnulib/../../install-sh -c -d
checking for struct timespec in ... yes
checking whether  uses 'inline' correctly... yes
checking for wint_t... yes
checking for alloca as a compiler built-in... yes
checking whether alphasort is declared without a macro... yes
checking whether closedir is declared without a macro... yes
checking whether dirfd is declared without a macro... yes
checking whether fdopendir is declared without a macro... yes
checking whether opendir is declared without a macro... yes
checking whether readdir is declared without a macro... yes
checking whether rewinddir is declared without a macro... yes
checking whether scandir is declared without a macro... yes
checking for dirfd... yes
checking whether dirfd is declared... (cached) yes
checking whether dirfd is a macro... no
checking whether // is distinct from /... (cached) no
checking for flexible array member... yes
checking whether conversion from 'int' to 'long double' works... yes
checking for working GNU fnmatch... no
checking whether isblank is declared... yes
checking whether isblank is declared... (cached) yes
checking whether frexp works... yes
checking whether frexpl is declared... yes
checking whether frexpl() can be used without linking with libm... yes
checking whether frexpl works... yes
checking whether gettimeofday clobbers localtime buffer... no
checking for gettimeofday with POSIX signature... yes
checking whether INT32_MAX < INTMAX_MAX... yes
checking whether INT64_MAX == LONG_MAX... yes
checking whether UINT32_MAX < UINTMAX_MAX... yes
checking whether UINT64_MAX == ULONG_MAX... yes
checking whether isnan(double) can be used without linking with libm... yes
checking whether isnan(long double) can be used without linking with libm... no
checking where to find the exponent in a 'long double'... word 2 bit 0
checking whether NAN macro works... yes
checking whether HUGE_VAL works... yes
checking whether acosf is declared without a macro... yes
checking whether acosl is declared without a macro... yes
checking whether asinf is declared without a macro... yes
checking whether asinl is declared without a macro... yes
checking whether atanf is declared without a macro... yes
checking whether atanl is declared without a macro... yes
checking whether cbrt is declared without a macro... yes
checking whether cbrtf is declared without a macro... yes
checking whether cbrtl is declared without a macro... yes
checking whether ceilf is declared without a macro... yes
checking whether ceill is declared without a macro... yes
checking whether copysign is declared without a macro... yes
checking whether copysignf is declared without a macro... yes
checking whether copysignl is declared without a macro... yes
checking whether cosf is declared without a macro... yes
checking whether cosl is declared without a macro... yes
checking whether coshf is declared without a macro... 

GSOC'18 contribution plan

[Vidushi Vashishth]

Hello!

I am Vidushi Vashishth from Netaji Subhas Institute of Technology, Delhi
and I intend to participate in the selection procedure for GSOC'18. I have
already submitted the Hello world patch. The past couple of days I have
been going through the open projects and I am interested in the ones below:

1) Run time tracing
For this project I have been reading about the Common Trace Format
Integration, Trace Buffering, RTEMS trace linker's working which utilises
INI configuration files. I have been following the ticket #3028. I am
currently working on the tasks present on the ticket's description. It
would be helpful if the community could point out to any other relevant
issues which I could work on to get a better idea about this project. I
would get back when I find one myself. As suggested on the mailing list, I
would also like to investigate the TCF project to see if a combination of
both of these can be undertaken in one summer. Let me know if this is too
optimistic.

2) Rump Kernels
The project's description was a little open ended but garnered my interest.
It would require a little more research from my end to come up with ideas
myself. I would do that if time permits.

I intend to write my proposal in a week's time.

References:
https://devel.rtems.org/ticket/3028
https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels

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

Re: Hello World patch

[Vidushi Vashishth]

Hello!

I sent the patch to Gedare Bloom. The student tracking table is not
editable yet I think. Thanks for the list of projects. I will shortly get
back to you on which project I would contribute to.

Best,
Vidushi

On Tue, Jan 16, 2018 at 3:05 AM, Joel Sherrill <j...@rtems.org> wrote:

>
>
> On Mon, Jan 15, 2018 at 2:20 PM, Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> - Ursprüngliche Mail -
>> > Von: "Vidushi Vashishth" <reachv...@gmail.com>
>> > An: "RTEMS Devel" <devel@rtems.org>
>> > Gesendet: Montag, 15. Januar 2018 06:17:53
>> > Betreff: Hello World patch
>>
>> > Hi!
>> >
>> > I have the hello world patch and screenshot. Whom should I send it to?
>> >
>> > Best,
>> > Vidushi
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>> Hello Vidushi,
>>
>> I assume that you think of the patch and screenshot from the GSoC Getting
>> Started guide (https://devel.rtems.org/wiki/GSoC/GettingStarted)? In
>> that case: Quite a number of last years student's have sent that to the
>> mailing list. But I think you can also send it to Gedare Bloom directly. If
>> you send it to the list, please make sure that your screenshot isn't too
>> big. There is a size limit on the mailing list (I think around 100 or 200k)
>> and it will be delivered to a lot of people.
>>
>
> Sending it to Gedare or myself is fine.
>
> Also there is a student tracking page at https://devel.rtems.org/wik
> i/GSoC/2018 with a table you should add yourself to. You can leave the
> project TBD for now. But we can discuss project ideas
>
>
>>
>> It's really great that you are interested in working with us but please
>> note that you are quite early. Not everything is set up yet for GSoC2018.
>> For example a lot of wiki pages are still only updated partially. Beneath
>> that Google didn't even publish it's list of accepted organizations but we
>> had no problems in the last years so I would be quite optimistic.
>>
>> Of course you can already start to bond with the community. If you
>> already have project ideas you should discuss them with potential mentors
>> or - if you have no idea who might could be a mentor - discuss them on the
>> mailing list. If you don't have ideas, you can take a look over
>> https://devel.rtems.org/wiki/Developer/OpenProjects.
>>
>
> Christian is correct. It is quite early. We have applied and I have made a
> suggestion on what I personally think are the highest priority projects
> from an RTEMS project perspective. But that doesn't mean all have mentors
> or that someone in the community or a student doesn't have other ideas.
>
> My personal starting list for high priority projects was:
>
> + Wifi integration improvements (assuming Christian mentors)
> + aarch64 port
> + non-legacy PC support
> + coverage reporting changes and gcov support improvements
> + Eclipse target support for tracing and gdb (TCF?)
>
> I am sure there are other projects of merit. Those were just the ones off
> the top of my head.
>
> The Open Project page is a good place to start looking but some projects
> have had progress on them and others are possibly no longer relevant.
>
> --joel
>
>
>>
>> Best regards
>>
>> Christian Mauderer
>> --
>> 
>> embedded brains GmbH
>> Christian Mauderer
>> Dornierstr. 4
>> <https://maps.google.com/?q=Dornierstr.+4+%0D+D-82178+Puchheim+%0D+Germany=gmail=g>
>> D-82178 Puchheim
>> Germany
>> email: christian.maude...@embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax:   +49-89-18 94 741 - 08
>> 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
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Hello World patch

[Vidushi Vashishth]

Hi!

I have the hello world patch and screenshot. Whom should I send it to?

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