Re: [PATCH v2] sb: Fix the RTEMS options after strict option checking was added.
On 22/1/19 5:24 pm, Sebastian Huber wrote: > > Thanks, this works. See v2 of the default prefix patch. > Both are OK to push. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v4 0/8] Adding griscv bsp
On 21/01/2019 16:49, Jiri Gaisler wrote: Fourth take on adding a bsp for a RISC-V GRLIB cpu, taking into account previous comments. Jiri Gaisler (6): grlib: Fix inludes grlib: make apbuart driver independent of bsp grlib: use rtems_interrupt_handler_install() for all interrupt handlers grlib: use cpu-independent routines for uncached access grlib: make memory coherency cpu-independent riscv: add griscv bsp Sebastian Huber (2): grlib: Move header files grlib: Move source files I added a ticket for this BSP: http://devel.rtems.org/ticket/3678 I checked in a slightly modified patch set. For example to fix build errors with the leon2 BSP. I added also a documentation stub: https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html#griscv -- 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: FreeBSD 12 stable branch for libbsd
On 17/01/2019 09:29, Sebastian Huber wrote: Hello, I would like to add a "freebsd-12" branch to libbsd which tracks the FreeBSD 12 stable branch instead of the trunk. I would like to figure out if it is possible to maintain this branch more easily for production systems. The libbsd master will still track the trunk. I added the branch to libbsd: https://git.rtems.org/rtems-libbsd/log/?h=5-freebsd-12 -- 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
Hello Chris, On 20/12/2018 07:46, Sebastian Huber wrote: Sorry but I have no time to review this and consider it until next year. No problem, take your time. I work on this since April this year from time to time, so it can wait a couple of more weeks. had you time to look at this? The focus of this new stuff is the recording of high frequency events on multiple processors. It doesn't deal with filtering or event generation. Attached is a very simple example program to get the records via a TCP stream from the target. It outputs text like this: 6769.471369714:4:THREAD_ID:a01000a 6769.471369714:4:THREAD_QUEUE_ENQUEUE:7df04b1c 6769.471369734:5:UMA_FREE_PTR:7ee6ce00 6769.471369734:5:UMA_FREE_ZONE:7fee5000 6769.471370660:4:THREAD_STATE_SET:1 6769.471370660:4:THREAD_ID:a01000a 6769.471371180:5:THREAD_ID:a01000a 6769.471371180:5:THREAD_QUEUE_SURRENDER:7df04b1c 6769.471372274:4:THREAD_STATE_CLEAR:30015fff 6769.471372274:4:THREAD_ID:a01000a 6769.471372476:5:THREAD_ID:a010029 6769.471372476:5:THREAD_QUEUE_ENQUEUE:7dd24e84 6769.471373040:5:THREAD_STATE_SET:1 6769.471373040:5:THREAD_ID:a010029 6769.471374835:5:THREAD_SWITCH_IN:9010017 6769.471374835:5:THREAD_STACK_CURRENT:1890 6769.471374835:5:THREAD_SWITCH_OUT:a010029 6769.471378612:4:THREAD_ID:a010029 6769.471378612:4:THREAD_QUEUE_SURRENDER:7dd24e84 6769.471380229:4:THREAD_STATE_CLEAR:30015fff 6769.471380229:4:THREAD_ID:a010029 6769.471384143:4:ETHER_INPUT:7dd77100 6769.471384246:5:THREAD_SWITCH_IN:a010029 6769.471384246:5:THREAD_STACK_CURRENT:1ce0 6769.471384246:5:THREAD_SWITCH_OUT:9010017 6769.471384591:4:IP_INPUT:7dd77100 6769.471385216:5:TCP_OUTPUT:7dd21000 6769.471385232:4:TCP_INPUT:7dd77100 6769.471387009:5:WRITE:77 6769.471388103:4:TCP_OUTPUT:7dd21000 6769.471388337:5:RECVFROM:76 6769.471389260:4:UMA_ALLOC_PTR:7d210300 6769.471389260:4:UMA_ALLOC_ZONE:7fee6900 6769.471389760:4:IP_OUTPUT:7d210300 6769.471390693:4:ETHER_OUTPUT:7d210300 6769.471391167:4:UMA_ALLOC_PTR:7d22d8c0 6769.471391167:4:UMA_ALLOC_ZONE:7fee5c00 6769.471393095:4:ETHER_INPUT:7da55900 6769.471393594:4:IP_INPUT:7da55900 6769.471394090:4:TCP_INPUT:7da55900 6769.471394277:5:UMA_FREE_PTR:7da57900 6769.471394277:5:UMA_FREE_ZONE:7fee5000 6769.471398185:4:ETHER_INPUT:7da9e900 6769.471398534:4:IP_INPUT:7da9e900 6769.471399020:4:TCP_INPUT:7da9e90 A potential GSoC project could be to use visualize this. -- 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. >From 3b42571634e0de038c37397812d9ba0cab34077c Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Mon, 14 Jan 2019 13:28:31 +0100 Subject: [PATCH] rtems-record: New program --- misc/record/record-client.c | 448 +++ misc/record/record-main.c| 307 +++ misc/record/record-text.c| 197 + misc/record/rtems/recordclient.h | 139 misc/record/rtems/recorddata.h | 317 +++ misc/wscript | 10 + 6 files changed, 1418 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..1d84050 --- /dev/null +++ b/misc/record/record-client.c @@ -0,0 +1,448 @@ +/* + * SPDX-License-Identifier: BSD-2-Clause + * + * Copyright (C) 2018 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
[PATCH 2/2] sb: Change default prefix
Use OS prefix + "rtems" + $rtems_version as the default prefix to
automatically separate different RTEMS versions.
Close #3679.
---
source-builder/sb/options.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/source-builder/sb/options.py b/source-builder/sb/options.py
index 485..7d1856b 100644
--- a/source-builder/sb/options.py
+++ b/source-builder/sb/options.py
@@ -299,6 +299,12 @@ class command_line:
# Must have a host
if self.defaults['_build'] == self.defaults['nil']:
raise error.general('--build not set')
+# Default prefix
+prefix = self.parse_args('--prefix')
+if prefix is None:
+value = path.join(self.defaults['_prefix'], 'rtems',
str(version.version()))
+self.opts['prefix'] = value
+self.defaults['_prefix'] = value
# Manage the regression option
if self.opts['regression'] != '0':
self.opts['no-install'] = '1'
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] sb: Change Linux default prefix to "/opt"
http://refspecs.linuxbase.org/FHS_3.0/fhs/ch03s13.html#purpose14
Update #3679.
---
source-builder/sb/linux.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/source-builder/sb/linux.py b/source-builder/sb/linux.py
index 9d90288..e6c5470 100644
--- a/source-builder/sb/linux.py
+++ b/source-builder/sb/linux.py
@@ -63,6 +63,7 @@ def load():
'_host_arch': ('none','none', cpu),
'_usr': ('dir', 'required', '/usr'),
'_var': ('dir', 'required', '/var'),
+'_prefix': ('dir', 'optional', '/opt'),
'__bzip2': ('exe', 'required', '/usr/bin/bzip2'),
'__gzip': ('exe', 'required', '/bin/gzip'),
'__tar':('exe', 'required', '/bin/tar')
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/2] Patches for RSB 4.11 branch
Sebastian Huber (2): sb: Change Linux default prefix to "/opt" sb: Change default prefix source-builder/sb/linux.py | 1 + source-builder/sb/options.py | 6 ++ 2 files changed, 7 insertions(+) -- 2.16.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS Executive vs. Kernel
Hello, in the documentation sometimes the name "executive" and sometimes "kernel" is used for RTEMS itself. I think "kernel" should be better used for systems with a kernel/user space separation. I will use RTEMS executive throughout the documentation if nobody objects. -- 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
Reference names in Sphinx documentation
Hello, I would like to introduce a rule for the Sphinx documentation: "Use CamelCase for Sphinx reference names, e.g. .. _QuickStart:" The rational for this is that CamelCase is not used much in the RTEMS world, so this makes it easy to grep for references. -- 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: RTEMS Executive vs. Kernel
I think this is appropriate for terminology. On Tue, Jan 22, 2019 at 9:26 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > in the documentation sometimes the name "executive" and sometimes > "kernel" is used for RTEMS itself. I think "kernel" should be better > used for systems with a kernel/user space separation. I will use RTEMS > executive throughout the documentation if nobody objects. > > -- > 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: RTEMS Executive vs. Kernel
I mean, yes let's call it executive. There is no "kernel" in RTEMS. On Tue, Jan 22, 2019 at 11:32 AM Gedare Bloom wrote: > I think this is appropriate for terminology. > > On Tue, Jan 22, 2019 at 9:26 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello, >> >> in the documentation sometimes the name "executive" and sometimes >> "kernel" is used for RTEMS itself. I think "kernel" should be better >> used for systems with a kernel/user space separation. I will use RTEMS >> executive throughout the documentation if nobody objects. >> >> -- >> 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
Missing Test: simple binary semaphore with timeout?
Hello all, I'm debugging a problem for someone, and they appear to be using a simple binary semaphore with a timeout that might be triggering a bug. I can't find a test case for simple binary semaphores in RTEMS with timeout, am I missing something? I also don't see tests for binary semaphores with timeout that aren't using PIP. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Executive vs. Kernel
I don't object. However, if you go back in time to the early RTEMS days, executive and kernel were used interchangeably. Both were less full-featured than what was called an OS back in those days. Now that RTEMS has file systems, networking, etc, it is proper under those old conventions to use OS for RTEMS now but the concurrency and synchronization minimal subset is an executive/kernel. But executive is better than kernel now as a term. Executives focus on services related to managing a thread set. --joel On Tue, Jan 22, 2019 at 10:32 AM Gedare Bloom wrote: > I mean, yes let's call it executive. There is no "kernel" in RTEMS. > > On Tue, Jan 22, 2019 at 11:32 AM Gedare Bloom wrote: > >> I think this is appropriate for terminology. >> >> On Tue, Jan 22, 2019 at 9:26 AM Sebastian Huber < >> sebastian.hu...@embedded-brains.de> wrote: >> >>> Hello, >>> >>> in the documentation sometimes the name "executive" and sometimes >>> "kernel" is used for RTEMS itself. I think "kernel" should be better >>> used for systems with a kernel/user space separation. I will use RTEMS >>> executive throughout the documentation if nobody objects. >>> >>> -- >>> 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
Building Ada for RTEMS
Hi I put this on hold for the Christmas holidays and wanted to post what worked and didn't for me. This is on Centos 7 building C, C++ and Ada to target sparc-rtems5 using the RSB master. I tried various gcc versions with Ada support. I ensured which gcc I was using by putting it at the front of my PATH and doing "gcc --version" before I started the RSB build. + RSB build fails with base gcc from CentOS. It is gcc 4.8.5 + RSB build fails with gcc from git master. + RSB build fails with gcc 8.2.0 + RSB build succeeds with gcc 7.4.0 Notice that the build succeeds when using a native version that matches the version being built cross. This is in keeping with long-standing advice. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building Ada for RTEMS
On 23/1/19 9:04 am, Joel Sherrill wrote: > Notice that the build succeeds when using a native version that matches the > version being built cross. This is in keeping with long-standing advice. Should the RSB be taught to check for gcc and the native version if an Ada build is requested? Can we assume an Ada build fails with a clang native tool set? Should we provide a bare build set for the needed native gcc? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Executive vs. Kernel
On 23/1/19 5:34 am, Joel Sherrill wrote: > I don't object. Is executive the right abstraction? Both terms are an abstraction because we have a single address space and literal or formal interpretation breaks down. I see the physical separation as an implementation detail. Which term is the better abstraction of what the rtems.git repo is? This is the critical piece to resolve. I have been using kernel as the reference to the 'rtems.git' repo. Using 'rtems' as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' has a much broader scope these days and it's meaning is ambiguous to new users. RTEMS OS is also too board and ambiguous. I selected the term 'kernel' because it represents a formal set of interfaces that RTEMS provides without being specific about a piece of provided functionality. It also follows the RSB build set name I created years ago. The single term is strategic, it is attempting to use a language that maps to the steps you need to take and repos you need to access. The Executable section of the User Manual outlines the stages: https://docs.rtems.org/branches/master/user/exe/index.html A key focus of this section is to show the steps a user needs to take to build an application. They are building the tools, building the "kernel", optionally building 3rd party packages and then building an application. I include libbsd as a 3rd party package to be consistent and to show to users the RTEMS operating system can also contain 3rd party packages and those packages can serve as examples for others. We sit in a middle state at the moment, we have things in the rtems.git repo that could be separate packages, the legacy networking stack, parts of libmisc, or we have packages like libbsd that could be part of rtems.git. I suspect in time removing packages from the rtems.git repo will aid certification because there is less code to audit or review and remove. This however means we need a strong package builder or these packages as well as external 3rd party packages. Hmm, maybe the term 3rd party packages is wrong and should be changed, but that is off scope for this thread. Joel and I have been reviewing the Eco-system and Executable section of the user manual using both terms and in a few spots "RTEMS operating system" should be used instead of 'kernel' so that language could be improved. In the Executable section the use of 'executive' seems to close to 'executable'. Note, the "Kernel" layer in the "Vertical Software Stack" figure should be expanded to be two layers, "Services" and "Executive". An important factor is the documentation needs to read well. For me the executive is the runtime thread management and control, I suppose the score set of files, and I think it would be awkward to group the shell as part of the executive. Referring to 'rtems.git' as the 'executive' repo somehow does not feel right. I am not sure there is a clear answer that perfectly defines what we have. There seems to be a lot of work to make this change including the RSB and I am wondering if it is worth the churn. > However, if you go back in time to the early RTEMS days, executive and kernel > were used interchangeably. Both were less full-featured than what was called > an > OS back in those days. Now that RTEMS has file systems, networking, etc, it is > proper under those old conventions to use OS for RTEMS now but the concurrency > and synchronization minimal subset is an executive/kernel. Yes I agree we have used these terms equally over the years... https://docs.rtems.org/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/FAQ/FAQ6.html :) > But executive is better than kernel now as a term. Executives focus on > services > related to managing a thread set. How do we address the rtems.git repo? For example ... "Please refer to the code in the kernel repo" "Please refer to the code in the executive repo" "Please refer to the code in the OS repo" For me the executive sentence seems specialised while the kernel seem boarder but that could just be my ingrained view. If we use executive is 'exec' as a shorted path ok? For example: /opt/work/chris/rtems/exec/rtems.git If 'executive' is used we are again extending path names and we there can be issues even on Linux, ie Ada builds and Windows. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building Ada for RTEMS
On Tue, Jan 22, 2019 at 4:08 PM Chris Johns wrote: > On 23/1/19 9:04 am, Joel Sherrill wrote: > > Notice that the build succeeds when using a native version that matches > the > > version being built cross. This is in keeping with long-standing advice. > > Should the RSB be taught to check for gcc and the native version if an Ada > build > is requested? > That's a good question. If the native gcc version does not have Ada support, it will be a definite failure. Technically, a range of versions of the native gcc might work but I have never had much luck unless at least the major versions of the native and cross source were the same. This might require some magic to check and could be overly rigid. And I could be biased since on CentOS, the native compiler is so old that you really have no hope it is going to work. I should check if gcc 6 works. For a native build, you were supposed to be able to use one major number back but I recall that doesn't work for cross builds reliably. > > Can we assume an Ada build fails with a clang native tool set? > I think so. I don't think you get Ada with clang, do you? > > Should we provide a bare build set for the needed native gcc? > Another good idea to discuss. I don't use the built native compiler except to build the cross. If we install it with the RTEMS tools, we could create other complexities. FWIW my procedure is pretty simple, I untar, use the contrib/download_prerequisites script, and then build with no configure args except prefix and languages. --joel > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building Ada for RTEMS
Hello Joel, On 22/01/2019 23:04, Joel Sherrill wrote: Hi I put this on hold for the Christmas holidays and wanted to post what worked and didn't for me. This is on Centos 7 building C, C++ and Ada to target sparc-rtems5 using the RSB master. I tried various gcc versions with Ada support. I ensured which gcc I was using by putting it at the front of my PATH and doing "gcc --version" before I started the RSB build. + RSB build fails with base gcc from CentOS. It is gcc 4.8.5 + RSB build fails with gcc from git master. + RSB build fails with gcc 8.2.0 + RSB build succeeds with gcc 7.4.0 Notice that the build succeeds when using a native version that matches the version being built cross. This is in keeping with long-standing advice. the current situation for GCC 9 is less good. I was not able to build it on Debian: https://gcc.gnu.org/ml/gcc/2019-01/msg00141.html On openSUSE it worked. -- 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
On 23/1/19 12:34 am, Sebastian Huber wrote: > Hello Chris, > > On 20/12/2018 07:46, Sebastian Huber wrote: >>> >>> Sorry but I have no time to review this and consider it until next year. >> >> No problem, take your time. I work on this since April this year from time to >> time, so it can wait a couple of more weeks. > > had you time to look at this? > Sorry I have not. I understand there is a need for high performance tracing and welcome this work. I have tended to use custom code to handle this, an example is https://git.rtems.org/rtems/tree/cpukit/dev/i2c/xilinx-axi-i2c.c#n120. > The focus of this new stuff is the recording of high frequency events on > multiple processors. It doesn't deal with filtering or event generation. Like the idea but I am confused on how what is being offered fits into what we have. It seems to provide better performance but it also overlaps some of what we have and is missing some other things. I cannot tell from my brief look if it sits as a component in the existing RTEMS trace framework or it is completely separate. I am OK with something new and better but we need to make sure what we offer is consistent and makes sense to users. I am concerned users will become confused if we have multiple approaches with separate code, set up, post processing and documentation. I am fine if what we have is replaced and removed if your new approach is to become a complete framework. Filtering and triggering as implemented is important in some cases to make sure the overhead and transport processes does not become unstable but it costs at run-time. If done property the overhead could be small. Manually inserting trace points is problematic for some users and wrapping has limitations. I am not sure we can have a single approach for all use cases. > Attached is a very simple example program to get the records via a TCP stream > from the target. It outputs text like this: How have you inserted the trace points on the target in this example? Again I am missing the high level view. Is this in the detail of the other patch? A common transport approach would be nice for all pieces of the trace puzzle. > A potential GSoC project could be to use visualize this. This would be nice and count me in helping. CTF seems to be still well supported. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Executive vs. Kernel
On 22/01/2019 23:42, Chris Johns wrote: On 23/1/19 5:34 am, Joel Sherrill wrote: I don't object. Is executive the right abstraction? Both terms are an abstraction because we have a single address space and literal or formal interpretation breaks down. I see the physical separation as an implementation detail. Real-Time Executive for Multiprocessor Systems or RTEMS already has executive in its name. I don't think that the kernel/user space separation and system calls are an implementation detail. It is a hardware enforced feature which characterizes a whole group of operating systems. The name kernel is quite overloaded. I would like to avoid that someone thinks about RTEMS as a micro kernel which would be totally wrong. Which term is the better abstraction of what the rtems.git repo is? This is the critical piece to resolve. Ok, this is a different issue. The problem is that in rtems.git is a collection of different things. It contains the RTEMS executive (everything which deals with threads, interrupts, synchronization and inter-thread communication), a legacy network stack, file systems, device drivers, memory allocators, compression libraries, hash libraries, shell, etc. I think calling this stuff "kernel" is imprecise. I have been using kernel as the reference to the 'rtems.git' repo. Using 'rtems' as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' has a much broader scope these days and it's meaning is ambiguous to new users. RTEMS OS is also too board and ambiguous. I selected the term 'kernel' because it represents a formal set of interfaces that RTEMS provides without being specific about a piece of provided functionality. It also follows the RSB build set name I created years ago. The single term is strategic, it is attempting to use a language that maps to the steps you need to take and repos you need to access. The Executable section of the User Manual outlines the stages: https://docs.rtems.org/branches/master/user/exe/index.html A key focus of this section is to show the steps a user needs to take to build an application. They are building the tools, building the "kernel", optionally building 3rd party packages and then building an application. I include libbsd as a 3rd party package to be consistent and to show to users the RTEMS operating system can also contain 3rd party packages and those packages can serve as examples for others. We sit in a middle state at the moment, we have things in the rtems.git repo that could be separate packages, the legacy networking stack, parts of libmisc, or we have packages like libbsd that could be part of rtems.git. I suspect in time removing packages from the rtems.git repo will aid certification because there is less code to audit or review and remove. This however means we need a strong package builder or these packages as well as external 3rd party packages. Hmm, maybe the term 3rd party packages is wrong and should be changed, but that is off scope for this thread. Joel and I have been reviewing the Eco-system and Executable section of the user manual using both terms and in a few spots "RTEMS operating system" should be used instead of 'kernel' so that language could be improved. In the Executable section the use of 'executive' seems to close to 'executable'. Note, the "Kernel" layer in the "Vertical Software Stack" figure should be expanded to be two layers, "Services" and "Executive". An important factor is the documentation needs to read well. For me the executive is the runtime thread management and control, I suppose the score set of files, and I think it would be awkward to group the shell as part of the executive. Referring to 'rtems.git' as the 'executive' repo somehow does not feel right. I am not sure there is a clear answer that perfectly defines what we have. There seems to be a lot of work to make this change including the RSB and I am wondering if it is worth the churn. I think it is worth the churn. If you don't name the important components consistently in the documentation it is just confusing. However, if you go back in time to the early RTEMS days, executive and kernel were used interchangeably. Both were less full-featured than what was called an OS back in those days. Now that RTEMS has file systems, networking, etc, it is proper under those old conventions to use OS for RTEMS now but the concurrency and synchronization minimal subset is an executive/kernel. Yes I agree we have used these terms equally over the years... https://docs.rtems.org/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/FAQ/FAQ6.html :) But executive is better than kernel now as a term. Executives focus on services related to managing a thread set. How do we address the rtems.git repo? For example ... "Please refer to the code in the kernel repo" "Please refer to the code in the executive repo" "Please refer to the code in the OS repo" For me the executive sentence seems
Re: RTEMS Executive vs. Kernel
On 23/1/19 5:50 pm, Sebastian Huber wrote: > On 22/01/2019 23:42, Chris Johns wrote: >> On 23/1/19 5:34 am, Joel Sherrill wrote: >>> I don't object. >> Is executive the right abstraction? Both terms are an abstraction because we >> have a single address space and literal or formal interpretation breaks >> down. I >> see the physical separation as an implementation detail. > > Real-Time Executive for Multiprocessor Systems or RTEMS already has executive > in > its name. The name has evolved over time. > I don't think that the kernel/user space separation and system calls > are an implementation detail. It is a hardware enforced feature which > characterizes a whole group of operating systems. The name kernel is quite > overloaded. It sure is. > I would like to avoid that someone thinks about RTEMS as a micro > kernel which would be totally wrong. I think there will always be a level of confusion. >> Which term is the better abstraction of what the rtems.git repo is? This is >> the >> critical piece to resolve. > > Ok, this is a different issue. The problem is that in rtems.git is a > collection > of different things. It contains the RTEMS executive (everything which deals > with threads, interrupts, synchronization and inter-thread communication), a > legacy network stack, file systems, device drivers, memory allocators, > compression libraries, hash libraries, shell, etc. I think calling this stuff > "kernel" is imprecise. It is imprecise but what is a precise single word or term to explain this? >> >> I have been using kernel as the reference to the 'rtems.git' repo. Using >> 'rtems' >> as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' >> has >> a much broader scope these days and it's meaning is ambiguous to new users. >> RTEMS OS is also too board and ambiguous. I selected the term 'kernel' >> because >> it represents a formal set of interfaces that RTEMS provides without being >> specific about a piece of provided functionality. It also follows the RSB >> build >> set name I created years ago. The single term is strategic, it is attempting >> to >> use a language that maps to the steps you need to take and repos you need to >> access. The Executable section of the User Manual outlines the stages: >> >> https://docs.rtems.org/branches/master/user/exe/index.html >> >> A key focus of this section is to show the steps a user needs to take to >> build >> an application. They are building the tools, building the "kernel", >> optionally >> building 3rd party packages and then building an application. I include >> libbsd >> as a 3rd party package to be consistent and to show to users the RTEMS >> operating >> system can also contain 3rd party packages and those packages can serve as >> examples for others. >> >> We sit in a middle state at the moment, we have things in the rtems.git repo >> that could be separate packages, the legacy networking stack, parts of >> libmisc, >> or we have packages like libbsd that could be part of rtems.git. I suspect in >> time removing packages from the rtems.git repo will aid certification because >> there is less code to audit or review and remove. This however means we need >> a >> strong package builder or these packages as well as external 3rd party >> packages. >> Hmm, maybe the term 3rd party packages is wrong and should be changed, but >> that >> is off scope for this thread. >> >> Joel and I have been reviewing the Eco-system and Executable section of the >> user >> manual using both terms and in a few spots "RTEMS operating system" should be >> used instead of 'kernel' so that language could be improved. In the >> Executable >> section the use of 'executive' seems to close to 'executable'. >> >> Note, the "Kernel" layer in the "Vertical Software Stack" figure should be >> expanded to be two layers, "Services" and "Executive". >> >> An important factor is the documentation needs to read well. >> >> For me the executive is the runtime thread management and control, I suppose >> the >> score set of files, and I think it would be awkward to group the shell as >> part >> of the executive. Referring to 'rtems.git' as the 'executive' repo somehow >> does >> not feel right. >> >> I am not sure there is a clear answer that perfectly defines what we have. >> There >> seems to be a lot of work to make this change including the RSB and I am >> wondering if it is worth the churn. > > I think it is worth the churn. If you don't name the important components > consistently in the documentation it is just confusing. Sorry, of course the work is worth it if we have a term to use. I was meaning for me kernel is only marginally better than executive so that change is not worth it. I think it is important to keep executive for the list you have provided below. >>> However, if you go back in time to the early RTEMS days, executive and >>> kernel >>> were used interchangeably. Both were less full-featured than what was >>
Re: [PATCH] Add low level event recording support
On 23/01/2019 07:49, Chris Johns wrote: On 23/1/19 12:34 am, Sebastian Huber wrote: Hello Chris, On 20/12/2018 07:46, Sebastian Huber wrote: Sorry but I have no time to review this and consider it until next year. No problem, take your time. I work on this since April this year from time to time, so it can wait a couple of more weeks. had you time to look at this? Sorry I have not. I understand there is a need for high performance tracing and welcome this work. I have tended to use custom code to handle this, an example is https://git.rtems.org/rtems/tree/cpukit/dev/i2c/xilinx-axi-i2c.c#n120. You could use the record support of this patch set for this purpose. The focus of this new stuff is the recording of high frequency events on multiple processors. It doesn't deal with filtering or event generation. Like the idea but I am confused on how what is being offered fits into what we have. It seems to provide better performance but it also overlaps some of what we have and is missing some other things. I cannot tell from my brief look if it sits as a component in the existing RTEMS trace framework or it is completely separate. It closes a gap in the existing stuff, recording of high frequency events on a multiprocessor platform. For example in the output of the previous e-mail you see: 6769.471385216:5:TCP_OUTPUT:7dd21000 6769.471385232:4:TCP_INPUT:7dd77100 These two events on different processors are separated by 16ns. It is impossible to get this independence with a recording facility which uses locks (atomic read-modify-write) or a global time source. You need per-processor data structures with per-processor synchronization and a per-processor time source for this. It is not complicated, it is just a ring buffer per processor. I am OK with something new and better but we need to make sure what we offer is consistent and makes sense to users. I am concerned users will become confused if we have multiple approaches with separate code, set up, post processing and documentation. I am fine if what we have is replaced and removed if your new approach is to become a complete framework. There is no one size fits all. This stuff just solves one problem and tries to do it well. You need other components that work together to get a good tracing solution for RTEMS. This is a major piece of work. Providing a documentation set along is a lot of work. Maybe we can use GSoC projects in this area. Filtering and triggering as implemented is important in some cases to make sure the overhead and transport processes does not become unstable but it costs at run-time. If done property the overhead could be small. Manually inserting trace points is problematic for some users and wrapping has limitations. I am not sure we can have a single approach for all use cases. Attached is a very simple example program to get the records via a TCP stream from the target. It outputs text like this: How have you inserted the trace points on the target in this example? Again I am missing the high level view. Is this in the detail of the other patch? I tried to use the GNU ld --wrap, but this didn't work well since it wraps only undefined references. I had also a look at extending GNU ld to support also defined references, but this turned out to be quite difficult to me. Some events are generated by user extensions. In the network stack I used code patches. The focus of this recording stuff is not the event generation, the filtering, the transport from A to B, visualization, etc. The focus is event recording of high frequency events on multiprocessor platforms. It is just one tiny building block that can be used in a tracing infrastructure. A common transport approach would be nice for all pieces of the trace puzzle. I think that transformation to standard formats should be done on a host computer and not the target. -- 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
On 23/1/19 6:13 pm, Sebastian Huber wrote: > On 23/01/2019 07:49, Chris Johns wrote: >> On 23/1/19 12:34 am, Sebastian Huber wrote: >>> Hello Chris, >>> >>> On 20/12/2018 07:46, Sebastian Huber wrote: > Sorry but I have no time to review this and consider it until next year. No problem, take your time. I work on this since April this year from time to time, so it can wait a couple of more weeks. >>> had you time to look at this? >>> >> Sorry I have not. >> >> I understand there is a need for high performance tracing and welcome this >> work. >> I have tended to use custom code to handle this, an example is >> https://git.rtems.org/rtems/tree/cpukit/dev/i2c/xilinx-axi-i2c.c#n120. > > You could use the record support of this patch set for this purpose. Yes, I can see this. >>> The focus of this new stuff is the recording of high frequency events on >>> multiple processors. It doesn't deal with filtering or event generation. >> Like the idea but I am confused on how what is being offered fits into what >> we >> have. It seems to provide better performance but it also overlaps some of >> what >> we have and is missing some other things. I cannot tell from my brief look >> if it >> sits as a component in the existing RTEMS trace framework or it is completely >> separate. > > It closes a gap in the existing stuff, recording of high frequency events on a > multiprocessor platform. For example in the output of the previous e-mail you > see: > > 6769.471385216:5:TCP_OUTPUT:7dd21000 > 6769.471385232:4:TCP_INPUT:7dd77100 > > These two events on different processors are separated by 16ns. It is > impossible > to get this independence with a recording facility which uses locks (atomic > read-modify-write) or a global time source. You need per-processor data > structures with per-processor synchronization and a per-processor time source > for this. It is not complicated, it is just a ring buffer per processor. Thanks for the detail. >> I am OK with something new and better but we need to make sure what we offer >> is >> consistent and makes sense to users. I am concerned users will become >> confused >> if we have multiple approaches with separate code, set up, post processing >> and >> documentation. I am fine if what we have is replaced and removed if your new >> approach is to become a complete framework. > > There is no one size fits all. This stuff just solves one problem and tries to > do it well. You need other components that work together to get a good tracing > solution for RTEMS. This is a major piece of work. Providing a documentation > set > along is a lot of work. Maybe we can use GSoC projects in this area. I do not think documentation is allowed as GSoC projects. It can be part of a development effort but not as a stand alone project. >> Filtering and triggering as implemented is important in some cases to make >> sure >> the overhead and transport processes does not become unstable but it costs at >> run-time. If done property the overhead could be small. Manually inserting >> trace >> points is problematic for some users and wrapping has limitations. I am not >> sure >> we can have a single approach for all use cases. >> >>> Attached is a very simple example program to get the records via a TCP >>> stream >>> from the target. It outputs text like this: >> How have you inserted the trace points on the target in this example? Again >> I am >> missing the high level view. Is this in the detail of the other patch? > > I tried to use the GNU ld --wrap, but this didn't work well since it wraps > only > undefined references. I had also a look at extending GNU ld to support also > defined references, but this turned out to be quite difficult to me. I am sure. I suspect we may have to look for other solutions such as DWARF. > Some events are generated by user extensions. In the network stack I used code > patches. The focus of this recording stuff is not the event generation, the > filtering, the transport from A to B, visualization, etc. The focus is event > recording of high frequency events on multiprocessor platforms. It is just one > tiny building block that can be used in a tracing infrastructure. This is great to hear. Should all the existing trace code be brought together in libtrace? >> A common transport approach would be nice for all pieces of the trace puzzle. > > I think that transformation to standard formats should be done on a host > computer and not the target. I agree. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add low level event recording support
On 23/01/2019 08:23, Chris Johns wrote: I am OK with something new and better but we need to make sure what we offer is consistent and makes sense to users. I am concerned users will become confused if we have multiple approaches with separate code, set up, post processing and documentation. I am fine if what we have is replaced and removed if your new approach is to become a complete framework. There is no one size fits all. This stuff just solves one problem and tries to do it well. You need other components that work together to get a good tracing solution for RTEMS. This is a major piece of work. Providing a documentation set along is a lot of work. Maybe we can use GSoC projects in this area. I do not think documentation is allowed as GSoC projects. It can be part of a development effort but not as a stand alone project. I guess to get the data into LTTng and visualized requires some coding. However, I see the main effort in documentation. Filtering and triggering as implemented is important in some cases to make sure the overhead and transport processes does not become unstable but it costs at run-time. If done property the overhead could be small. Manually inserting trace points is problematic for some users and wrapping has limitations. I am not sure we can have a single approach for all use cases. Attached is a very simple example program to get the records via a TCP stream from the target. It outputs text like this: How have you inserted the trace points on the target in this example? Again I am missing the high level view. Is this in the detail of the other patch? I tried to use the GNU ld --wrap, but this didn't work well since it wraps only undefined references. I had also a look at extending GNU ld to support also defined references, but this turned out to be quite difficult to me. I am sure. I suspect we may have to look for other solutions such as DWARF. Some events are generated by user extensions. In the network stack I used code patches. The focus of this recording stuff is not the event generation, the filtering, the transport from A to B, visualization, etc. The focus is event recording of high frequency events on multiprocessor platforms. It is just one tiny building block that can be used in a tracing infrastructure. This is great to hear. Should all the existing trace code be brought together in libtrace? Yes, I guess grouping the sources would help a bit, but a high level documentation of the tracing pieces we have would be more helpful. -- 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: Missing Test: simple binary semaphore with timeout?
On 22/01/2019 17:35, Gedare Bloom wrote: Hello all, I'm debugging a problem for someone, and they appear to be using a simple binary semaphore with a timeout that might be triggering a bug. I can't find a test case for simple binary semaphores in RTEMS with timeout, am I missing something? I also don't see tests for binary semaphores with timeout that aren't using PIP. I would be not surprised if a test is missing. For the self-contained binary semaphores there are some simple tests here: testsuites/sptests/spthread01/init.c The timeout handling is contained in thread queues, so this code is covered by a lot of other test cases. -- 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
