Re: Event Recording/CTF: Unexpected end of packet

[Ravindra Kumar Meena]

>
> 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 closing the files in
> the record client.
>
With your, fix. This error is not occurring now. Thanks


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

[PATCH] common: Add ECSS standard references

[Sebastian Huber]

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 100644
--- 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 - Practical Multithreading}},
   year= {2012},
   isbn= {978-1933988771},
   publisher   = {Manning Publications Co},
@@ -355,3 +355,54 @@
   title = {{RTEMS CPU Architecture Supplement}},
   url   = {https://docs.rtems.org/branches/master/cpu-supplement.pdf},
 }
+% ECSS
+% Sort lexicographically
+@manual{ECSS_E_ST_10_02C_R1,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-E-ST-10-02C - Space engineering - Verification}},
+  year = {2018},
+  url  = 
{https://ecss.nl/standard/ecss-e-st-10-02c-rev-1-verification-1-february-2018/},
+}
+@manual{ECSS_E_ST_10_06C,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-E-ST-10-06C - Technical requirements specification}},
+  year = {2009},
+  url  = 
{https://ecss.nl/standard/ecss-e-st-10-06c-technical-requirements-specification/},
+}
+@manual{ECSS_E_ST_10C_R1,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-E-ST-10C Rev.1 - System engineering general 
requirements}},
+  year = {2017},
+  url  = 
{https://ecss.nl/standard/ecss-e-st-10c-rev-1-system-engineering-general-requirements-15-february-2017/},
+}
+@manual{ECSS_E_ST_40C,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-E-ST-40C - Software general requirements}},
+  year = {2009},
+  url  = 
{https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/},
+}
+@manual{ECSS_M_ST_40C_R1,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-M-ST-40C Rev.1 - Configuration and information 
management}},
+  year = {2009},
+  url  = 
{https://ecss.nl/standard/ecss-m-st-40c-rev-1-configuration-and-information-management/},
+}
+@manual{ECSS_Q_ST_80C_R1,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-Q-ST-80C Rev.1 - Software product assurance}},
+  year = {2017},
+  url  = 
{https://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/},
+}
+@manual{ECSS_S_ST_00_01C,
+  author   = {ECSS},
+  organization = {European Cooperation for Space Standardization},
+  title= {{ECSS-S-ST-00-01C - Glossary of terms}},
+  year = {2012},
+  url  = 
{https://ecss.nl/standard/ecss-s-st-00-01c-glossary-of-terms-1-october-2012/},
+}
-- 
2.16.4

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

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

[Vaibhav Gupta]

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.
.
.
This time I also added files generated by `autoreconf -fvi` in the patch.
.
This patch is 10MB in size hence cannot be send in raw format on mailing
list.
.
This patch worked with RSB and ndbm library (lib_a-ndbm.o) was generated
successfully in RTEMS Toolchain.


Thank you
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] common: Add ECSS standard references

[Sebastian Huber]

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 - Practical Multithreading}},


Sorry for this unrelated change, it changes a non-ASCII "-" into a "-".

--
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 2019 | POSIX Compliance - Need further guidance on fenv sources.

[Vaibhav Gupta]

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 should I go for particular source for a specific architecture?

1.1) - ARM FreeBSD Source:
- https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
- https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
.
1.2) - ARM NetBSD Source :
- https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
- https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
-
2.1) - SPARC NetBSD Source :
- https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
- https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c

3.1) - PPC FreeBSD Source:
- https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
- https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
.
3.2) - PPC NetBSD Source:
- https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
- https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
---
4.1) - x86 FreeBSD Source:
- https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
.
4.2) - x86 NetBSD Source:
- https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
--
5.1) - RISC5 FreeBSD Source:
- https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
- https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
.
5.2) - RISC5 NetBSD Source:
- https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
- https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c


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

Requirement Identifiers

[Sebastian Huber]

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 basic element is 
that requirements can be identified. We have to discuss how requirements 
are identified in the RTEMS project.


The proposed tool to manage requirements in RTEMS is Doorstop:

https://github.com/jacebrowning/doorstop

This tool add some restrictions to the way requirements are identified.

The following text is a part of my requirements engineering draft 
document in ReST format.


Identification
--

Each requirement shall have a unique identifier (UID).  The open 
question is in
which scope should it be unique?  Ideally, it should be universally 
unique. As

a best effort approach, the name *RTEMS* shall be used as a part in all
requirement identifiers. This should ensure that the RTEMS requirements 
can be
referenced easily in larger systems.  The standard ECSS-E-ST-10-06C 
recommends
in section 8.2.6 that the identifier should reflect the type of the 
requirement

and the life profile situation.  Other standards may have other
recommendations.  To avoid a bias of RTEMS in the direction of ECSS, this
recommendation will not be followed.  In addition, it would also make 
the use
of :term:`Doorstop` more difficult, since this tool does not support 
attribute

dependent identifiers.

.. topic:: Doorstop

The UID of an item (requirement) is defined by its file name 
without the
extension. An UID consists of two parts, the prefix and a number. 
The parts

are divided by an optional separator. The prefix is determined by the
document to which the item belongs.

Proposal: Default Doorstop Numbering


One UID scheme for RTEMS requirements is the concatenation of *RTEMS* and a
5-digit number which is automatically generated by Doorstop.  It starts with
RTEMS1 and ends with RTEMS9.  These identifiers are just unique and
bear no other information.

Proposal: Number Groups
~~~

Another UID scheme for RTEMS requirements is the concatenation of 
*RTEMS* and a
5-digit number which reflects the hierarchy of requirements.  For 
example UIDs

from RTEMS01000 to RTEMS01999 are task requirements, UIDs from RTEMS02000 to
RTEMS02999 are semaphore requirements, UIDs from RTEMS03000 to 
RTEMS03999 are
message queue requirements, etc.  It would be also possible to add a 
separator

character, for example RTEMS-01234.

.. topic:: Doorstop

This is currently not supported by Doorstop, see `issue #349
`_.

Proposal: Document Hierarchy


Another UID scheme for RTEMS requirements is the concatenation of 
*RTEMS*, one
or more component names, and a 3-digit number which reflects the 
hierarchy of

requirements.  Each part is separated by a "-" character.  For example UIDs
from RTEMS-Classic-Task-001 to RTEMS-Classic-Task-999 are task requirements,
UIDs from RTEMS-Classic-Semaphore-001 to RTEMS-Classic-Semaphore-999 are
semaphore requirements, UIDs from RTEMS-Classic-MQ-001 to 
RTEMS-Classic-MQ-999
are message queue requirements, etc.  The benefit is that requirement 
files are

organized in directories.

.. topic:: Doorstop

Doorstop uses documents to create namespaces (named a prefix in 
Doorstop).

For the example above, you can create the documents like this:

.. code-block:: none

doorstop create -d 3 RTEMS-Classic -p RTEMS reqs/classic
doorstop create -d 3 RTEMS-Classic-Task -p RTEMS-Classic 
reqs/classic/task
doorstop create -d 3 RTEMS-Classic-Semaphore -p RTEMS-Classic 
reqs/classic/semaphore
doorstop create -d 3 RTEMS-Classic-MQ -p RTEMS-Classic 
reqs/classic/mq



--
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: Event Recording/CTF: Get closer to LTTNG output

[Ravindra Kumar Meena]

>
> 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 {
> uint32_t magic;
> uint8_t  uuid[16];
> uint32_t stream_id;
> uint64_t stream_instance_id;
> };
> };
>
I have added the ctf magic(0xC1FC1FC1) in header. I am facing difficulty in
adding uuid in header. uuid is 128 a bit number which has 5 octets of
8-4-4-4-12 bytes. So this is something i did:

#define UUID_octet_1 0x6a7715d0
#define UUID_octet_2 0xb502
#define UUID_octet_3 0x4c65
#define UUID_octet_4 0x8678
#define UUID_octet_5 0x6777ac7f755a

typedef struct bit_field
{
unsigned x: 12; // 12 bits
} bit_field;

typedef struct ctf_uuid {
  uint32_t   octet1;
  uint16_t   octet2;
  uint16_t   octet3;
  uint16_t   octet4;
  bit_field  octet5;
} ctf_uuid;

The babeltrace has recognized the ctf magic number but not able to
recognize uuid. Is there something else method to add uuid in header?


> Move the generation of the metadata file to the record client.
>
> Generate the clock dynamically, e.g. the use the current CLOCK_REALTIME
> to set the offset.
>
> clock {
> name = "monotonic";
> uuid = "234d669d-7651-4bc1-a7fd-af581ecc6232";
> description = "Monotonic Clock";
> freq = 10; /* Frequency, in Hz */
> /* clock value offset from Epoch is: offset * (1/freq) */
> offset = 1539783991179109789;
> };
>
> Add a LTTNG compatible packet context:
>
> struct packet_context {
> uint64_clock_monotonic_t timestamp_begin;
> uint64_clock_monotonic_t timestamp_end;
> uint64_t content_size;
> uint64_t packet_size;
> uint64_t packet_seq_num;
> unsigned long events_discarded;
> uint32_t cpu_id;
> };
>
Okay


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

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

[Sebastian Huber]

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-6777ac7f755a";
         byte_order = le;
         packet.header := struct {
                 uint32_t magic;
                 uint8_t  uuid[16];


Why don't you simply use the above in your C code as well?


                 uint32_t stream_id;
                 uint64_t stream_instance_id;
         };
};

I have added the ctf magic(0xC1FC1FC1) in header. I am facing difficulty 
in adding uuid in header. uuid is 128 a bit number which has 5 octets of 
8-4-4-4-12 bytes.

[...]

--
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 2019 | POSIX Compliance - RSB patch generated ndbm library (lib_a-ndbm.o) successfully in RTEMS Toolchain

[Joel Sherrill]

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 applied same patch to RSB hence ndbm library was not generated.
> .
>
In my local build yesterday, I saw the symbols in the installed libc.a. I
have not run the tests.


> .
> This time I also added files generated by `autoreconf -fvi` in the patch.
> .
> This patch is 10MB in size hence cannot be send in raw format on mailing
> list.
>

The person committing is supposed to do the autoreconf and commit that.

No one has answered if it is OK to commit. That was the last message in the
thread.


> .
> This patch worked with RSB and ndbm library (lib_a-ndbm.o) was generated
> successfully in RTEMS Toolchain.
>

I'm hoping we can avoid this by pushing the patch to newlib, then bumping
the hash for
newlib in the RSB, then adding your ndbm test patch to RTEMS.

--joel


>
>
> Thank you
> Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Identifiers

[Joel Sherrill]

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 be much
easier
to manage long term if you could easily correlate requirements with
managers,
handlers, libraries, etc.

On Thu, Jul 11, 2019 at 3:15 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> 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 basic element is
> that requirements can be identified. We have to discuss how requirements
> are identified in the RTEMS project.
>
> The proposed tool to manage requirements in RTEMS is Doorstop:
>
> https://github.com/jacebrowning/doorstop
>
> This tool add some restrictions to the way requirements are identified.
>
> The following text is a part of my requirements engineering draft
> document in ReST format.
>
> Identification
> --
>
> Each requirement shall have a unique identifier (UID).  The open
> question is in
> which scope should it be unique?  Ideally, it should be universally
> unique. As
> a best effort approach, the name *RTEMS* shall be used as a part in all
> requirement identifiers. This should ensure that the RTEMS requirements
> can be
> referenced easily in larger systems.  The standard ECSS-E-ST-10-06C
> recommends
> in section 8.2.6 that the identifier should reflect the type of the
> requirement
> and the life profile situation.  Other standards may have other
> recommendations.  To avoid a bias of RTEMS in the direction of ECSS, this
> recommendation will not be followed.  In addition, it would also make
> the use
> of :term:`Doorstop` more difficult, since this tool does not support
> attribute
> dependent identifiers.
>
> .. topic:: Doorstop
>
>  The UID of an item (requirement) is defined by its file name
> without the
>  extension. An UID consists of two parts, the prefix and a number.
> The parts
>  are divided by an optional separator. The prefix is determined by the
>  document to which the item belongs.
>
> Proposal: Default Doorstop Numbering
> 
>
> One UID scheme for RTEMS requirements is the concatenation of *RTEMS* and a
> 5-digit number which is automatically generated by Doorstop.  It starts
> with
> RTEMS1 and ends with RTEMS9.  These identifiers are just unique and
> bear no other information.
>
> Proposal: Number Groups
> ~~~
>
> Another UID scheme for RTEMS requirements is the concatenation of
> *RTEMS* and a
> 5-digit number which reflects the hierarchy of requirements.  For
> example UIDs
> from RTEMS01000 to RTEMS01999 are task requirements, UIDs from RTEMS02000
> to
> RTEMS02999 are semaphore requirements, UIDs from RTEMS03000 to
> RTEMS03999 are
> message queue requirements, etc.  It would be also possible to add a
> separator
> character, for example RTEMS-01234.
>
> .. topic:: Doorstop
>
>  This is currently not supported by Doorstop, see `issue #349
>  `_.
>
> Proposal: Document Hierarchy
> 
>
> Another UID scheme for RTEMS requirements is the concatenation of
> *RTEMS*, one
> or more component names, and a 3-digit number which reflects the
> hierarchy of
> requirements.  Each part is separated by a "-" character.  For example UIDs
> from RTEMS-Classic-Task-001 to RTEMS-Classic-Task-999 are task
> requirements,
> UIDs from RTEMS-Classic-Semaphore-001 to RTEMS-Classic-Semaphore-999 are
> semaphore requirements, UIDs from RTEMS-Classic-MQ-001 to
> RTEMS-Classic-MQ-999
> are message queue requirements, etc.  The benefit is that requirement
> files are
> organized in directories.
>
> .. topic:: Doorstop
>
>  Doorstop uses documents to create namespaces (named a prefix in
> Doorstop).
>  For the example above, you can create the documents like this:
>
>  .. code-block:: none
>
>  doorstop create -d 3 RTEMS-Classic -p RTEMS reqs/classic
>  doorstop create -d 3 RTEMS-Classic-Task -p RTEMS-Classic
> reqs/classic/task
>  doorstop create -d 3 RTEMS-Classic-Semaphore -p RTEMS-Classic
> reqs/classic/semaphore
>  doorstop create -d 3 RTEMS-Classic-MQ -p RTEMS-Classic
> reqs/classic/mq
>
>
> --
> 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.
> 

Re: Requirement Identifiers

[Sebastian Huber]

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 custom attributes, such as type and verification-method, so 
we need a custom documentation generator anyway:


YAML files -> Doorstop -> Custom Translator -> Sphinx/ReST -> PDF | HTML

It will be sections or chapters not documents.

--
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: Event Recording/CTF: Get closer to LTTNG output

[Ravindra Kumar Meena]

>
> >  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] = 0x6a7715d0b5024c6586786777ac7f755a;

>
> >  uint32_t stream_id;
> >  uint64_t stream_instance_id;
> >  };
> > };
> >
> > I have added the ctf magic(0xC1FC1FC1) in header. I am facing difficulty
> > in adding uuid in header. uuid is 128 a bit number which has 5 octets of
> > 8-4-4-4-12 bytes.
> [...]
>


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

How to get started?

[Niteesh]

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 would be greatly appreciated.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Build failed for RTEMS Source Builder

[Himanshu Sekhar Nayak]

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
testing under MX Linux which is also a debian based distro. Any idea ?

here is the error report https://paste.ofcode.org/37fg9TKr2q77Thwh5j8Yqxf

Thanks
Himanshu Sekhar Nayak
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Build failed for RTEMS Source Builder

[Chris Johns]

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 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 testing 
> under
> MX Linux which is also a debian based distro. Any idea ?
> 
> here is the error report https://paste.ofcode.org/37fg9TKr2q77Thwh5j8Yqxf
> 

I do not understand why sed is set to
/home/himanshu/quick-start/rtems/5/usr/bin/sed. The error report is saying it
has been found at /usr/bin/sed.

I suggest running with `--trace` and inspecting the log to see if this helps
explain why it is getting confused.

Chris



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

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

[Vaibhav Gupta]

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` , `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.
>> .
>>
> In my local build yesterday, I saw the symbols in the installed libc.a. I
> have not run the tests.
>
>
>> .
>> This time I also added files generated by `autoreconf -fvi` in the patch.
>> .
>> This patch is 10MB in size hence cannot be send in raw format on mailing
>> list.
>>
>
> The person committing is supposed to do the autoreconf and commit that.
>
> No one has answered if it is OK to commit. That was the last message in
> the thread.
>
I will ping on that thread again for confirmation.

>
>
>> .
>> This patch worked with RSB and ndbm library (lib_a-ndbm.o) was generated
>> successfully in RTEMS Toolchain.
>>
>
> I'm hoping we can avoid this by pushing the patch to newlib, then bumping
> the hash for
> newlib in the RSB, then adding your ndbm test patch to RTEMS.
>
Yeah, meanwhile testsuite can be verified.
.
Also, please look at the sources I send on devel for fenv. Should I ignore
architectures
which are not having FreeBSD source? or Should i pick from NetBSD and
FreeBSD
both?

>
> --joel
>
>
>>
>>
>> Thank you
>> Vaibhav Gupta
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Ravindra Kumar Meena]

>
> 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 was thinking in the wrong direction. I have now added uuid also in
the stream header.

https://github.com/rmeena840/rtems-tools/commit/fa17148220dfd9a1df1f3d8cfad0b4afd19c331f

https://github.com/rmeena840/rtems-tools/commit/05dbb29c72a5cceee054a996a8e799520d7b2817

Tested on AWS. No warnings.

In the packet.header you mentioned to added stream_instance_id. See below.
What is it? In the documentation it is mentioned that packet.header can
only contain three values(magic, uuid, stream_id).

trace {
major = 1;
minor = 8;
uuid = "6a7715d0-b502-4c65-8678-6777ac7f755a";
byte_order = le;
packet.header := struct {
uint32_t magic;
uint8_t  uuid[16];
uint32_t stream_id;
uint64_t stream_instance_id;
};
};


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

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

[Sebastian Huber]

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_header.uuid[16] = 0x6a7715d0b5024c6586786777ac7f755a;


Okay. I was thinking in the wrong direction.


Could you please obtain a C language book for the remainder of this 
project. You have very basic issues with this programming language. I 
don't have time to teach you very basic C as a side-effect of this GSoC 
project.


I simplified the uuid initialization a bit:

https://github.com/rmeena840/rtems-tools/commit/5fc194cc1f04f8feea980243e5997f7cd6f91313

I have now added uuid also 
in the stream header.


https://github.com/rmeena840/rtems-tools/commit/fa17148220dfd9a1df1f3d8cfad0b4afd19c331f

https://github.com/rmeena840/rtems-tools/commit/05dbb29c72a5cceee054a996a8e799520d7b2817

Tested on AWS. No warnings.

In the packet.header you mentioned to added stream_instance_id. See below.
What is it? 


I don't know. Please ask this on the LTTNG mailing list. For now just 
add this field and set it to zero.


In the documentation it is mentioned that packet.header can 
only contain three values(magic, uuid, stream_id).


Which documentation, which section?



trace {
         major = 1;
         minor = 8;
         uuid = "6a7715d0-b502-4c65-8678-6777ac7f755a";
         byte_order = le;
         packet.header := struct {
                 uint32_t magic;
                 uint8_t  uuid[16];
                 uint32_t stream_id;
                 uint64_t stream_instance_id;
         };
};


LTTNG uses this stuff, so please use it also as is.

Please name the structures in the code and the CFT metadata 
consistently. You have at least these structures:


* packet header

* packet context

* event header

* event context

* specific events

You currently have only:

typedef struct ctf_header {
  uint32_t ctf_magic;
  uint8_t  uuid[ 16 ];
  uint32_t stream_id;
  uint32_t cpu_id;
} ctf_header;

typedef struct ctf_event {
  uint64_t ns;
  rtems_record_event   event;
  uint64_t data;
} __attribute__((__packed__)) ctf_event;

You have to re-organize this to match the LTTNG structures.

--
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 Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

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

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