GSoC Project | Basic Support for Trace Compass

Hi, I have added the stream_instance_id and set it to 0. I have raised a query on lltng mailing list for the same. https://github.com/rmeena840/rtems-tools/commit/44552ac5bb9eca70008f1784aa15419d3cf98b8b https://github.com/rmeena840/rtems-tools/commit/4525ca1770ed9233e59e1e5c185d13003a2913b7 --

Re: Event Recording/CTF: Get closer to LTTNG output

On 12/07/2019 05:58, Ravindra Kumar Meena wrote: Why don't you simply use the above in your C code as well? Yes. I tried that but compiler reports the value is too large. ../misc/record/record-main.c:357:27: warning: integer constant is too large for its type      ctf_he

Re: Event Recording/CTF: Get closer to LTTNG output

> > Why don't you simply use the above in your C code as well? >> > Yes. I tried that but compiler reports the value is too large. > ../misc/record/record-main.c:357:27: warning: integer constant is too > large for its type > ctf_header.uuid[16] = 0x6a7715d0b5024c6586786777ac7f755a; > Okay. I

Re: GSoC 2019 | POSIX Compliance - RSB patch generated ndbm library (lib_a-ndbm.o) successfully in RTEMS Toolchain

Sounds good to me. On Thu, Jul 11, 2019 at 6:47 PM Joel Sherrill wrote: > > > On Thu, Jul 11, 2019 at 2:12 AM Vaibhav Gupta > wrote: > >> Hello, >> After Joel pointed out in an offlist discussion, >> I made a new patch for ndbm port. >> . >> To send the changes to Newlib, i had to place `ndbm.h

Re: Build failed for RTEMS Source Builder

On 12/7/19 7:26 am, Himanshu Sekhar Nayak wrote: > Hello guys, > > I am trying to setup the rtems source builder from this > linkhttps://docs.rtems.org/branches/master/user/overview/index.html > but build is > failing due to autocon

Build failed for RTEMS Source Builder

Hello guys, I am trying to setup the rtems source builder from this link https://docs.rtems.org/branches/master/user/overview/index.html but build is failing due to autoconf. I have also gone through pre-requirments that need for the setup to build but seems like autoconf is failing it. Btw I am t

How to get started?

Hii, I am currently a sophomore pursuing Electronics and communication engineering. I have basic knowledge of operating systems and C. I would love to contribute to the project to improve my knowledge of real-time systems. I have hello world running, but have no idea on where to move next. Any help

Re: Event Recording/CTF: Get closer to LTTNG output

> > > uint8_t uuid[16]; > > Why don't you simply use the above in your C code as well? > Yes. I tried that but compiler reports the value is too large. ../misc/record/record-main.c:357:27: warning: integer constant is too large for its type ctf_header.uuid[16] = 0x6a7715d

Re: Requirement Identifiers

On 11/07/2019 15:19, Joel Sherrill wrote: Early on, we discussed that there wasn't a Rest backend to Doorstop. If we are having to add that anyway, can each "category" be generated as a chapter? We could generate 100+ chapters but we can't have 100+ requirements documents. We will have custo

Re: Requirement Identifiers

Early on, we discussed that there wasn't a Rest backend to Doorstop. If we are having to add that anyway, can each "category" be generated as a chapter? We could generate 100+ chapters but we can't have 100+ requirements documents. I lean strongly to needing categories of requirements. It would b

Re: GSoC 2019 | POSIX Compliance - RSB patch generated ndbm library (lib_a-ndbm.o) successfully in RTEMS Toolchain

On Thu, Jul 11, 2019 at 2:12 AM Vaibhav Gupta wrote: > Hello, > After Joel pointed out in an offlist discussion, > I made a new patch for ndbm port. > . > To send the changes to Newlib, i had to place `ndbm.h` , `ndbm.c` in their > respective places and make changes in Makefile.am. > Before, I a

Re: Event Recording/CTF: Get closer to LTTNG output

On 11/07/2019 11:24, Ravindra Kumar Meena wrote: the basic structure is now similar to the LTTNG output. The next step is to produce a packet header identical to LTTNG: trace {         major = 1;         minor = 8;         uuid = "6a7715d0-b502-4c65-8678-6777ac7f75

Re: Event Recording/CTF: Get closer to LTTNG output

> > the basic structure is now similar to the LTTNG output. The next step is > to produce a packet header identical to LTTNG: > > trace { > major = 1; > minor = 8; > uuid = "6a7715d0-b502-4c65-8678-6777ac7f755a"; > byte_order = le; > packet.header := struct {

Requirement Identifiers

Hello, I work currently on a requirements engineering section for RTEMS in the RTEMS Software Engineering manual: https://docs.rtems.org/branches/master/eng/index.html The goal is to add a technical specification for a subset of RTEMS. A technical specification consists of requirements. One

GSoC 2019 | POSIX Compliance - Need further guidance on fenv sources.

Hello, I have found sources for fenv. It's impossible to depend on either NetBSD or FreeBSD. . For some architectures, FreeBSD has code, for some, NetBSD has. . For x86, Free BSD has explicit header and NetBSD has .c file. . . So should I leave architectures which are not having FreeBSD Source? Or

Re: [PATCH] common: Add ECSS standard references

On 11/07/2019 09:09, Sebastian Huber wrote: --- a/common/refs.bib +++ b/common/refs.bib @@ -222,7 +222,7 @@ } @book{Williams:2012:CA, author = {Williams, Anthony}, - title = {{C++ Concurrency in Action – Practical Multithreading}}, + title = {{C++ Concurrency in Action

GSoC 2019 | POSIX Compliance - RSB patch generated ndbm library (lib_a-ndbm.o) successfully in RTEMS Toolchain

Hello, After Joel pointed out in an offlist discussion, I made a new patch for ndbm port. . To send the changes to Newlib, i had to place `ndbm.h` , `ndbm.c` in their respective places and make changes in Makefile.am. Before, I applied same patch to RSB hence ndbm library was not generated. . . Th

[PATCH] common: Add ECSS standard references

Add the ECSS standards in a separate block. Use a custom label scheme to make citations easier. --- common/refs.bib | 53 - 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/common/refs.bib b/common/refs.bib index c6bd4cf..e7d716c 10

Re: Event Recording/CTF: Unexpected end of packet

> > please fix this error reported by babeltrace: > > [error] Unexpected end of packet. Either the trace data stream is > corrupted or metadata description does not match data layout. > [error] Reading event failed. > Error printing trace. > > I think this has something to do with not properly clos