psim failures with -O1

2019-01-29 Thread Chris Johns 
Hi,

I thought it may be a good idea to set the optimization level for the psim BSP
to `-O1`. The xilinx_zynq_a9_qemu has this and it is useful.

The change causes the number of test failures to jump from around 20 to over 
230.

Is this expected?

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

[PATCH] build: Do not install test programs

2019-01-29 Thread Sebastian Huber 
---
 testsuites/aclocal/env-rtemsbsp.m4 | 2 --
 testsuites/benchmarks/Makefile.am  | 4 +---
 testsuites/fstests/Makefile.am | 4 +---
 testsuites/libtests/Makefile.am| 3 +--
 testsuites/mptests/Makefile.am | 4 +---
 testsuites/psxtests/Makefile.am| 4 +---
 testsuites/psxtmtests/Makefile.am  | 3 +--
 testsuites/rhealstone/Makefile.am  | 4 +---
 testsuites/samples/Makefile.am | 4 +---
 testsuites/smptests/Makefile.am| 4 +---
 testsuites/sptests/Makefile.am | 4 +---
 testsuites/tmtests/Makefile.am | 4 +---
 12 files changed, 11 insertions(+), 33 deletions(-)

diff --git a/testsuites/aclocal/env-rtemsbsp.m4 
b/testsuites/aclocal/env-rtemsbsp.m4
index 3f70348faf..1cca7d9f83 100644
--- a/testsuites/aclocal/env-rtemsbsp.m4
+++ b/testsuites/aclocal/env-rtemsbsp.m4
@@ -24,6 +24,4 @@ AC_SUBST(RTEMS_BSP)
 AC_SUBST([PROJECT_INCLUDE],["\$(PROJECT_ROOT)/lib/include"])
 AC_SUBST([PROJECT_LIB],["\$(PROJECT_ROOT)/lib"])
 AC_SUBST([PROJECT_RELEASE],["\$(PROJECT_ROOT)"])
-
-AC_SUBST([rtems_testsdir],["\$(libdir)/rtems-][_RTEMS_API][/tests"])
 ])
diff --git a/testsuites/benchmarks/Makefile.am 
b/testsuites/benchmarks/Makefile.am
index f4a16417fb..8b49c40fa1 100644
--- a/testsuites/benchmarks/Makefile.am
+++ b/testsuites/benchmarks/Makefile.am
@@ -43,6 +43,4 @@ whetstone_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_whetstone) \
 whetstone_LDADD = -lm $(LDADD)
 endif
 
-rtems_tests_PROGRAMS = $(benchmarks)
-dist_rtems_tests_DATA = $(benchmark_screens) $(benchmark_docs)
-
+noinst_PROGRAMS = $(benchmarks)
diff --git a/testsuites/fstests/Makefile.am b/testsuites/fstests/Makefile.am
index 83d3ae82ff..3e787bc773 100644
--- a/testsuites/fstests/Makefile.am
+++ b/testsuites/fstests/Makefile.am
@@ -640,6 +640,4 @@ mrfs_fstime_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_mrfs_fstime) \
$(support_includes) $(test_includes) -I$(top_srcdir)/mrfs_support
 endif
 
-rtems_tests_PROGRAMS = $(fs_tests)
-dist_rtems_tests_DATA = $(fs_screens) $(fs_docs)
-
+noinst_PROGRAMS = $(fs_tests)
diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index cb632f8d88..8d27578484 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -1396,5 +1396,4 @@ writev_norun_SOURCES = POSIX/writev.c
 writev_norun_LDADD = $(RTEMS_ROOT)cpukit/librtemsdefaultconfig.a $(LDADD)
 endif
 
-rtems_tests_PROGRAMS = $(lib_tests)
-dist_rtems_tests_DATA = $(lib_screens) $(lib_docs)
+noinst_PROGRAMS = $(lib_tests)
diff --git a/testsuites/mptests/Makefile.am b/testsuites/mptests/Makefile.am
index 3624642cba..7111e2d109 100644
--- a/testsuites/mptests/Makefile.am
+++ b/testsuites/mptests/Makefile.am
@@ -243,6 +243,4 @@ mp14_node2_CPPFLAGS = -DNODE_NUMBER=2 $(AM_CPPFLAGS) 
$(TEST_FLAGS_mp14) \
 endif
 endif
 
-rtems_tests_PROGRAMS = $(mp_tests)
-dist_rtems_tests_DATA = $(mp_screens) $(mp_docs)
-
+noinst_PROGRAMS = $(mp_tests)
diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 3b1c36338a..749258cc0c 100644
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -1894,7 +1894,5 @@ lib_a_SOURCES = psxhdrs/devctl/posix_devctl.c \
 ## lib_a_SOURCES += psxhdrs/utmpx/pututxline.c   See ticket #3661
 endif
 
-rtems_tests_PROGRAMS = $(psx_tests)
+noinst_PROGRAMS = $(psx_tests)
 noinst_LIBRARIES = $(psx_lib)
-dist_rtems_tests_DATA = $(psx_screens) $(psx_docs)
-
diff --git a/testsuites/psxtmtests/Makefile.am 
b/testsuites/psxtmtests/Makefile.am
index 2702e0b035..1f22850ebf 100644
--- a/testsuites/psxtmtests/Makefile.am
+++ b/testsuites/psxtmtests/Makefile.am
@@ -636,5 +636,4 @@ psxtmthreadattr01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxtmthreadattr01) \
-DOPERATION_COUNT=$(OPERATION_COUNT)
 endif
 
-rtems_tests_PROGRAMS = $(psxtm_tests)
-dist_rtems_tests_DATA = $(psxtm_screens) $(psxtm_docs)
+noinst_PROGRAMS = $(psxtm_tests)
diff --git a/testsuites/rhealstone/Makefile.am 
b/testsuites/rhealstone/Makefile.am
index 574c9cf455..bb214357fc 100644
--- a/testsuites/rhealstone/Makefile.am
+++ b/testsuites/rhealstone/Makefile.am
@@ -67,6 +67,4 @@ rhtaskswitch_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_rhtaskswitch) \
$(support_includes) -I$(top_srcdir)/../tmtests/include
 endif
 
-rtems_tests_PROGRAMS = $(rhealstones)
-dist_rtems_tests_DATA = $(rhealstone_screens) $(rhealstone_docs)
-
+noinst_PROGRAMS = $(rhealstones)
diff --git a/testsuites/samples/Makefile.am b/testsuites/samples/Makefile.am
index f78d75ea04..f05c9a3689 100644
--- a/testsuites/samples/Makefile.am
+++ b/testsuites/samples/Makefile.am
@@ -156,6 +156,4 @@ unlimited_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_unlimited) 
\
$(support_includes)
 endif
 
-rtems_tests_PROGRAMS = $(samples)
-dist_rtems_tests_DATA = $(sample_screens) $(sample_docs)
-
+noinst_PROGRAMS = $(samples)
diff --git a/testsuites/smptests/Makefile.am b/testsuites/smptests/Makefile.am
index b5c2803d02..01076abaa9 100644
--- a/testsuites/smptests/Makefile.am
+++ b/testsuites/smptests/Makefile.am
@@ -659,6 +659

Re: [PATCH] Add low level event recording support

2019-01-29 Thread Chris Johns 
On 28/1/19 9:55 pm, Sebastian Huber wrote:
> 
> how do we want to proceed with this?
> 

You have answered my concerns and I am happy with what you are doing and this
piece of code.

I look forward to seeing the trace code being moved into libtrace or something
like this and seeing it grow as a unified package that make's sense to our 
users.

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

Re: [PATCH] Add low level event recording support

2019-01-29 Thread Sebastian Huber 

On 29/01/2019 09:27, Chris Johns wrote:

On 28/1/19 9:55 pm, Sebastian Huber wrote:

how do we want to proceed with this?


You have answered my concerns and I am happy with what you are doing and this
piece of code.


Thanks for your review and comments.



I look forward to seeing the trace code being moved into libtrace or something
like this and seeing it grow as a unified package that make's sense to our 
users.


It looks like a good GSoC project.

Should I move the code to cpukit/libtrace/record instead of 
cpukit/libmisc/record?


I am still struggling with the LD --wrap feature:

https://www.sourceware.org/ml/binutils/2019-01/msg00241.html

--
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: psim failures with -O1

2019-01-29 Thread Sebastian Huber 

On 29/01/2019 09:14, Chris Johns wrote:

Hi,

I thought it may be a good idea to set the optimization level for the psim BSP
to `-O1`. The xilinx_zynq_a9_qemu has this and it is useful.

The change causes the number of test failures to jump from around 20 to over 
230.

Is this expected?


Yes, this is a compiler bug/feature. GCC generates a floating point 
instruction in a function which is called in ISR context. This leads to 
an exception.


On SPARC using -O0 to run the tests is also problematic due to the much 
higher stack usage.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH] Add low level event recording support

2019-01-29 Thread Chris Johns 
On 29/1/19 7:40 pm, Sebastian Huber wrote:
> On 29/01/2019 09:27, Chris Johns wrote:
>> On 28/1/19 9:55 pm, Sebastian Huber wrote:
>>> how do we want to proceed with this?
>>>
>> You have answered my concerns and I am happy with what you are doing and this
>> piece of code.
> 
> Thanks for your review and comments.
> 
>>
>> I look forward to seeing the trace code being moved into libtrace or 
>> something
>> like this and seeing it grow as a unified package that make's sense to our 
>> users.
> 
> It looks like a good GSoC project.

Excellent idea.

> 
> Should I move the code to cpukit/libtrace/record instead of 
> cpukit/libmisc/record?
> 

Yes you might as well if that is OK with you?

> I am still struggling with the LD --wrap feature:
> 
> https://www.sourceware.org/ml/binutils/2019-01/msg00241.html
> 

I am watching. I wish I could help but I do not know the ld code at all.

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

Re: psim failures with -O1

2019-01-29 Thread Chris Johns 
On 29/1/19 7:48 pm, Sebastian Huber wrote:
> On 29/01/2019 09:14, Chris Johns wrote:
>> Hi,
>>
>> I thought it may be a good idea to set the optimization level for the psim 
>> BSP
>> to `-O1`. The xilinx_zynq_a9_qemu has this and it is useful.
>>
>> The change causes the number of test failures to jump from around 20 to over 
>> 230.
>>
>> Is this expected?
> 
> Yes, this is a compiler bug/feature. GCC generates a floating point 
> instruction
> in a function which is called in ISR context. This leads to an exception.

OK.

> 
> On SPARC using -O0 to run the tests is also problematic due to the much higher
> stack usage.
> 

OK.

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

[PATCH] rtems-record: New program

2019-01-29 Thread Sebastian Huber 
---
 misc/record/record-client.c  | 448 +++
 misc/record/record-main.c| 309 +++
 misc/record/record-text.c| 197 +
 misc/record/rtems/recordclient.h | 139 
 misc/record/rtems/recorddata.h   | 317 +++
 misc/wscript |  10 +
 6 files changed, 1420 insertions(+)
 create mode 100644 misc/record/record-client.c
 create mode 100644 misc/record/record-main.c
 create mode 100644 misc/record/record-text.c
 create mode 100644 misc/record/rtems/recordclient.h
 create mode 100644 misc/record/rtems/recorddata.h

diff --git a/misc/record/record-client.c b/misc/record/record-client.c
new file mode 100644
index 000..585aa38
--- /dev/null
+++ b/misc/record/record-client.c
@@ -0,0 +1,448 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2018, 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file must be compatible to general purpose POSIX system, e.g. Linux,
+ * FreeBSD.  It may be used for utility programs.
+ */
+
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+static void set_to_bt_scaler(
+  rtems_record_client_context *ctx,
+  uint32_t frequency
+)
+{
+  uint64_t bin_per_s;
+
+  bin_per_s = UINT64_C( 1 ) << 32;
+  ctx->to_bt_scaler = ( ( bin_per_s << 31 ) + frequency - 1 ) / frequency;
+}
+
+static rtems_record_client_status call_handler(
+  const rtems_record_client_context *ctx,
+  uint64_t   bt,
+  rtems_record_event event,
+  uint64_t   data
+)
+{
+  uint32_t seconds;
+  uint32_t nanosec;
+
+  seconds = (uint32_t) ( bt >> 32 );
+  nanosec = (uint32_t) ( ( UINT64_C( 10 ) * (uint32_t) bt ) >> 32 );
+
+  return ( *ctx->handler )(
+seconds,
+nanosec,
+ctx->cpu,
+event,
+data,
+ctx->handler_arg
+  );
+}
+
+static void check_overflow(
+  const rtems_record_client_context *ctx,
+  const rtems_record_client_per_cpu *per_cpu,
+  uint32_t   new_head
+)
+{
+  uint32_t last_tail;
+  uint32_t last_head;
+  uint32_t capacity;
+  uint32_t new_content;
+  uint64_t bt;
+
+  last_tail = per_cpu->tail[ per_cpu->index ];
+  last_head = per_cpu->head[ per_cpu->index ];
+
+  if ( last_tail == last_head ) {
+return;
+  }
+
+  capacity = ( last_tail - last_head - 1 ) & ( ctx->count - 1 );
+  new_content = new_head - last_head;
+
+  if ( new_content <= capacity ) {
+return;
+  }
+
+  bt = ( per_cpu->uptime.time_accumulated * ctx->to_bt_scaler ) >> 31;
+  bt += per_cpu->uptime.bt;
+
+  call_handler(
+ctx,
+bt,
+RTEMS_RECORD_OVERFLOW,
+new_content - capacity
+  );
+}
+
+static rtems_record_client_status visit( rtems_record_client_context *ctx )
+{
+  rtems_record_client_per_cpu *per_cpu;
+  uint32_t time;
+  rtems_record_event   event;
+  uint64_t data;
+  uint64_t bt;
+
+  per_cpu = &ctx->per_cpu[ ctx->cpu ];
+  time = RTEMS_RECORD_GET_TIME( ctx->event );
+  event = RTEMS_RECORD_GET_EVENT( ctx->event );
+  data = ctx->data;
+
+  switch ( event ) {
+case RTEMS_RECORD_PROCESSOR:
+  if ( data >= RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT ) {
+return RTEMS_RECORD_CLIENT_ERROR_UNSUPPORTED_CPU;
+  }
+
+  ctx->cpu = (uint32_t) data;
+  per_cpu = &ctx->per_cpu[ ctx->cpu ];
+  break;
+case RTEMS_RECORD_UPTIME_LOW:
+  per_cpu->uptime.bt = (uint32_t) data;
+  per_cpu->uptime.time_at_bt = time;
+  per_cpu->uptime.time_last = time;
+  per_cpu->uptime.time_accumulated = 0;
+  time

Re: RTEMS Executive vs. Kernel

2019-01-29 Thread Gedare Bloom 
On Mon, Jan 28, 2019 at 4:49 PM Chris Johns  wrote:

> On 26/1/19 11:22 am, Joel Sherrill wrote:
> >
> >
> > On Fri, Jan 25, 2019, 5:15 PM Chris Johns  >  wrote:
> >
> > On 26/1/19 9:43 am, Joel Sherrill wrote:
> > > We have a full shelf of old reports. A few would be good to have
> > > mirrored at ftp.rtems.org  <
> http://ftp.rtems.org> if
> > DTIC has them.
> >
> > Sebastian and I have been discussing using ..
> >
> >  https://ftp.rtems.org/pub/contrib/docs
> >
> > for these type of documents. We have some others need to find a home
> for. Would
> > that suite you?
> >
> >
> > Sure. Do we start with the rteid and orkid docs already on the server?
>
> Great.
>
> > What organization?
>
> This is open for discussion. It would be nice to separate the groups at
> the top
> level for example:
>
>  arm/..
>  powerpc/..
>  rtems/..
>  standards/...
>
>
it makes sense to me. I'm sure I have some esoteric sparc manuals lying
around, myself


> ?
>
> Anyone with git write access should be able to add to the collection
> (untested).
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Executive vs. Kernel

2019-01-29 Thread Joel Sherrill 
On Tue, Jan 29, 2019, 9:02 AM Gedare Bloom 
>
> On Mon, Jan 28, 2019 at 4:49 PM Chris Johns  wrote:
>
>> On 26/1/19 11:22 am, Joel Sherrill wrote:
>> >
>> >
>> > On Fri, Jan 25, 2019, 5:15 PM Chris Johns > >  wrote:
>> >
>> > On 26/1/19 9:43 am, Joel Sherrill wrote:
>> > > We have a full shelf of old reports. A few would be good to have
>> > > mirrored at ftp.rtems.org  <
>> http://ftp.rtems.org> if
>> > DTIC has them.
>> >
>> > Sebastian and I have been discussing using ..
>> >
>> >  https://ftp.rtems.org/pub/contrib/docs
>> >
>> > for these type of documents. We have some others need to find a
>> home for. Would
>> > that suite you?
>> >
>> >
>> > Sure. Do we start with the rteid and orkid docs already on the server?
>>
>> Great.
>>
>
I am going to retract my thinking on contrib as the name. Something more
indicative of it being a collection of documents, papers etc.


>> > What organization?
>>
>> This is open for discussion. It would be nice to separate the groups at
>> the top
>> level for example:
>>
>>  arm/..
>>  powerpc/..
>>  rtems/..
>>  standards/...
>>
>>
> it makes sense to me. I'm sure I have some esoteric sparc manuals lying
> around, myself
>

I have a similar directory locally. I have architecture and boards at the
top level. Also have standards.

Below RTEMS we will need some organization for old Army stuff, papers, etc.

>
>
>> ?
>>
>> Anyone with git write access should be able to add to the collection
>> (untested).
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Zynq Runtime Socket Buffer Allocation Memory Reporting Question

2019-01-29 Thread Misra, Avinash 
Hi,

I have a question in regards to changing the size of the socket buffers on the 
Zynq. It would appear that I can't use the method described in Ch 4.3 of the 
Networking pdf since I don't have the Ethernet driver and attach functions 
defined in the BSP. I believe this is largely due to the fact that I had to 
build RTEMS without networking and then separately build and link BSD to my 
kernel. As such the only way that I have found to change the buffer size is by 
a series of ifconfig sysctl calls that I have to make use at run time. My call 
hierarchy is as such:

rtems_bsd_initialize()

Then a call to ifconifg to set up the Eth device, IP Address, NetMask, etc.

sysctl -w kern.ipc.maxsockbuf

systcl -w net.inet.udp.recvspace

sysctl -w kern.ipc.nmbclusters

I believe these allow me to effectively override the run time defaults for UDP 
receive buffers. A call to getsockopt() confirms this for me.

What I have noticed however, is that I don't seem to see the increased buffer 
allocation reported by either top, wkspace, or malloc info (keeping in mind 
that my heap and workspace are configured to be unified). Am I looking at the 
wrong place to find the allocation of the socket buffers or does RTEMS simply 
not know about the increased buffer size since this was done at run time? 
Please also let me know if this is also the wrong way to achieve what I'm 
trying to do (allocate more memory to my socket buffers). One of my big 
concerns right now with not seeing the updated memory utilization is RTEMS 
accidentally allocating other run time, statically allocated, variables and 
arrays into the same memory that the updated socket buffers are trying to 
occupy.

Thanks,
Avi




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

Re: Zynq Runtime Socket Buffer Allocation Memory Reporting Question

2019-01-29 Thread Sebastian Huber 

Hello Avinash,

On 30/01/2019 02:08, Misra, Avinash wrote:


Hi,

I have a question in regards to changing the size of the socket 
buffers on the Zynq. It would appear that I can’t use the method 
described in Ch 4.3 of the Networking pdf since I don’t have the 
Ethernet driver and attach functions defined in the BSP.




the networking guide is for the legacy network stack. The libbsd has 
some documentation here:


https://git.rtems.org/rtems-libbsd/tree/libbsd.txt

The network buffers are managed by UMA which uses a page allocator. The 
memory area managed by the page allocator is determined during library 
initialization. You can use the "vmstat -z" and "netstat -m" shell 
commands to figure out something about the memory usage of libbsd.


--
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