Re: [PATCH 4/4] score: Move per-CPU jobs support

2021-07-29 Thread Sebastian Huber 

On 29/07/2021 02:44, Chris Johns wrote:

+void _Per_CPU_Add_job( Per_CPU_Control *cpu, Per_CPU_Job *job )
+{
+  ISR_lock_Context lock_context;
+
+  _Atomic_Store_ulong( &job->done, 0, ATOMIC_ORDER_RELAXED );
+  _Assert( job->next == NULL );

Given the dispatch does not check the handler is adding ...

  _Assert( job->context->handler != NULL );

worth doing ?


Yes, good idea. I added this:

void _Per_CPU_Add_job( Per_CPU_Control *cpu, Per_CPU_Job *job )
{
  ISR_lock_Context lock_context;

  _Assert( job->context != NULL && job->context->handler != NULL );

  _Atomic_Store_ulong( &job->done, 0, ATOMIC_ORDER_RELAXED );
  _Assert( job->next == NULL );


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] score: Move per-CPU jobs support

2021-07-29 Thread Chris Johns 
On 29/7/21 5:19 pm, Sebastian Huber wrote:
> On 29/07/2021 02:44, Chris Johns wrote:
>>> +void _Per_CPU_Add_job( Per_CPU_Control *cpu, Per_CPU_Job *job )
>>> +{
>>> +  ISR_lock_Context lock_context;
>>> +
>>> +  _Atomic_Store_ulong( &job->done, 0, ATOMIC_ORDER_RELAXED );
>>> +  _Assert( job->next == NULL );
>> Given the dispatch does not check the handler is adding ...
>>
>>   _Assert( job->context->handler != NULL );
>>
>> worth doing ?
> 
> Yes, good idea. I added this:
> 
> void _Per_CPU_Add_job( Per_CPU_Control *cpu, Per_CPU_Job *job )
> {
>   ISR_lock_Context lock_context;
> 
>   _Assert( job->context != NULL && job->context->handler != NULL );
> 
>   _Atomic_Store_ulong( &job->done, 0, ATOMIC_ORDER_RELAXED );
>   _Assert( job->next == NULL );
> 

Nice.

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

Re: [PATCH rtems-libbsd v2 2/5] usb_template: Configure template driver only for CDC Ethernet

2021-07-29 Thread Chris Johns 
On 29/7/21 4:20 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> Am 29.07.21 um 02:07 schrieb Chris Johns:
>> On 29/7/21 1:10 am, Ahamed Husni wrote:
>>>
>>>
>>> On Wed, 28 Jul 2021, 17:27 Husni Faiz, >> > wrote:
>>>
>>>  Add the conditional macro to prevent the driver from referencing
>>>  the templates which are not imported yet.
>>>
>>>  Include functions which adds the hw.usb.template sysctl variable.
>>>
>>>  Signed-off-by: Husni Faiz >>  >
>>>  ---
>>>   freebsd/sys/dev/usb/template/usb_template.c | 4 
>>>   freebsd/sys/dev/usb/usb_device.c            | 8 ++--
>>>   2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>>  diff --git a/freebsd/sys/dev/usb/template/usb_template.c
>>>  b/freebsd/sys/dev/usb/template/usb_template.c
>>>  index 0650da15..76567e85 100644
>>>  --- a/freebsd/sys/dev/usb/template/usb_template.c
>>>  +++ b/freebsd/sys/dev/usb/template/usb_template.c
>>>  @@ -1433,12 +1433,15 @@ usb_temp_setup_by_index(struct usb_device 
>>> *udev,
>>>  uint16_t index)
>>>          usb_error_t err;
>>>
>>>          switch (index) {
>>>  +#ifndef __rtems__
>>>          case USB_TEMP_MSC:
>>>                  err = usb_temp_setup(udev, &usb_template_msc);
>>>                  break;
>>>  +#endif /* __rtems__ */
>>>          case USB_TEMP_CDCE:
>>>                  err = usb_temp_setup(udev, &usb_template_cdce);
>>>                  break;
>>>  +#ifndef __rtems__
>>>          case USB_TEMP_MTP:
>>>                  err = usb_temp_setup(udev, &usb_template_mtp);
>>>                  break;
>>>  @@ -1469,6 +1472,7 @@ usb_temp_setup_by_index(struct usb_device *udev,
>>>  uint16_t index)
>>>          case USB_TEMP_CDCEEM:
>>>                  err = usb_temp_setup(udev, &usb_template_cdceem);
>>>                  break;
>>>  +#endif /* __rtems__ */
>>>          default:
>>>                  return (USB_ERR_INVAL);
>>>          }
>>>  diff --git a/freebsd/sys/dev/usb/usb_device.c
>>> b/freebsd/sys/dev/usb/usb_device.c
>>>  index ee240949..619cae5a 100644
>>>  --- a/freebsd/sys/dev/usb/usb_device.c
>>>  +++ b/freebsd/sys/dev/usb/usb_device.c
>>>  @@ -28,6 +28,10 @@
>>>    * SUCH DAMAGE.
>>>    */
>>>
>>>  +#ifdef __rtems__
>>>  +#include 
>>>  +#endif
>>>  +
>>>   #ifdef USB_GLOBAL_INCLUDE_FILE
>>>   #include USB_GLOBAL_INCLUDE_FILE
>>>   #else
>>>  @@ -123,7 +127,7 @@ int usb_template = USB_TEMPLATE;
>>>   int    usb_template = -1;
>>>   #endif
>>>
>>>  -#ifndef __rtems__
>>>  +#if !defined(__rtems__) || defined(RTEMS_BSD_MODULE_DEV_USB_TEMPLATE)
>>
>> Is doing this supported by the freebsd-to-rtems.py script?
> 
> I sure hope that it is. I know that I used similar constructions in the past 
> and
> it seems that I'm not the only one, because I'm sure that I haven't touched 
> some
> of these files:

Hmm I thought this was being handled but it seems it is not.

> (Hope that get's through the mail well enoguth that it is readable. If not: 
> Just
> grep for "defined(__rtems__)" yourself.)
> 
> I don't think that our script touches the "#ifdef(__rtems__)" except maybe in
> some special header cases, does it? I thought that's basically how the rebase
> works: Just copying all that stuff unchanged to freebsd-org and then do a 
> rebase
> with all changes. The guards are more or less to make it simpler to see what's
> been added by RTEMS.

Yes.

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

Re: [PATCH rtems-libbsd 3/7] sys/kern: Add lockmgr support

2021-07-29 Thread Gedare Bloom 
On Wed, Jul 28, 2021 at 5:58 PM Chris Johns  wrote:
>
> On 29/7/21 9:42 am, Gedare Bloom wrote:
> > On Wed, Jul 28, 2021 at 5:05 PM Chris Johns  wrote:
> >> On 29/7/21 12:03 am, Gedare Bloom wrote:
> >>> On Tue, Jul 27, 2021 at 2:59 AM  wrote:
>  From: Chris Johns 
>  +static int
>  +lockmgr_upgrade(struct lock *lk, u_int flags, struct lock_object *ilk,
>  +   const char *file, int line)
>  +{
>  +  uintptr_t x, v;
>  +  int error = 0;
>  +  LOCK_LOG_LOCK("XUPGRADE", &lk->lock_object, 0, 0, file, line);
>  +  lockmgr_trace("xupgrade", 'I', lk);
>  +  v = lk->lk_lock;
>  +  x = v & ~LK_SHARE;
>  +  atomic_store_rel_ptr(&lk->lk_lock, x);
> >>>
> >>> I think this function is to upgrade a shared (waiters/spinner) lock to
> >>> non-shared (spinner) lock? I'm not confident about correctness here.
> >>> It looks to me like there can be a race condition if multiple waiters
> >>> attempt to upgrade in parallel. It works by a preemption after the
> >>> first waiter loads `v = lk->lk_lock` and then another waiter loads
> >>> `v`. Actually, there doesn't seem to be anything that prevents two
> >>> separate calls to upgrade the lock by different waiters in sequence
> >>> either. I could be wrong (of course).
> >>
> >> We do not support shared locks and we do not share specific paths through 
> >> locks
> >> so while the code may request a shared lock it is not shared.
> >>
> > ok that is helpful.
> >
> >> You could be correct and I welcome you reviewing the code in the FB kernel 
> >> this
> >> is based on.
> >>
> > I took a quick look.
>
> Thanks
>
> > the FB kernel uses spinning and
> > atomic_fcmpset_ptr instead, which I think exactly addresses this
> > problem.
>
> Is this something we should do or is this something we should not be worried 
> about?
>
I'd suggest a comment in there or so, just to clarify that we don't
support shared locks, and that this implementation would need to be
improved if so.

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

[PATCH] rtems: Generate

2021-07-29 Thread Sebastian Huber 
Change license to BSD-2-Clause according to file histories and
documentation re-licensing agreement.

Place the group into the I/O Manager group.  Add all source files to the
group.

Update #3899.
Update #3993.
---
 cpukit/include/rtems/bspIo.h| 274 +---
 cpukit/libcsupport/src/getchark.c   |   2 +-
 cpukit/libcsupport/src/printk.c |   7 +-
 cpukit/libcsupport/src/printk_plugin.c  |   9 +-
 cpukit/libcsupport/src/putk.c   |   7 +-
 cpukit/libcsupport/src/rtems_put_char.c |   8 +
 cpukit/libcsupport/src/rtems_putc.c |   2 +-
 cpukit/libcsupport/src/vprintk.c|   7 +-
 8 files changed, 225 insertions(+), 91 deletions(-)

diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index ad196dfd34..55ff96b2b6 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -1,154 +1,274 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
- * @brief Interface to Kernel Print Methods
+ * @ingroup RTEMSAPIKernelCharIO
  *
- * This include file defines the interface to kernel print methods.
+ * @brief This header file provides the kernel character input/output support
+ *   API.
  */
 
 /*
- *  COPYRIGHT (c) 1998 vale...@crf.canon.fr
- *  COPYRIGHT (c) 2011 On-Line Applications Research Corporation.
+ * Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
+ *
+ * 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.
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * 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 is part of the RTEMS quality process and was automatically
+ * generated.  If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://www.rtems.org/bugs.html
+ *
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
+ *
+ * https://docs.rtems.org
+ */
+
+/* Generated from spec:/rtems/io/if/header-3 */
+
 #ifndef _RTEMS_BSPIO_H
 #define _RTEMS_BSPIO_H
 
-#include 
-
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/io/if/group-3 */
+
 /**
- * @defgroup BSPIO Kernel Print Support
+ * @defgroup RTEMSAPIKernelCharIO Kernel Character I/O Support
  *
- * @ingroup RTEMSAPIPrintSupport
+ * @ingroup RTEMSAPIClassicIO
  *
- * This module contains all methods and support related to providing
- * kernel level print support.
- *
- * The following variables below are declared as extern and
- * MUST be declared and initialized in each BSP. Using this indirect
- * function, the functionality in this group is tailored for the BSP.
- *
- *  - BSP_output_char
- *  - BSP_poll_char
+ * @brief The kernel character input/output support is an extension of the @ref
+ *   RTEMSAPIClassicIO to input and output characters to a BSP defined device
+ *   using a polled and non-blocking implementation.
  */
 
+/* Generated from spec:/rtems/io/if/bsp-output-char-function-type */
+
 /**
- * This type defines the prototype for the BSP provided method to
- * print a single character. It is assumed to be polled.
+ * @ingroup RTEMSAPIKernelCharIO
+ *
+ * @brief Polled character output functions shall have this type.
  */
-typedef void   (*BSP_output_char_function_type)(char c);
+typedef void ( *BSP_output_c

Re: [PATCH] rtems: Generate

2021-07-29 Thread Sebastian Huber 

On 29/07/2021 14:51, Sebastian Huber wrote:

Change license to BSD-2-Clause according to file histories and
documentation re-licensing agreement.

Place the group into the I/O Manager group.  Add all source files to the
group.

Update #3899.
Update #3993.


It would be easy to add a chapter for this to the Classic API Guide (for 
example "Kernel Character I/O Support"):


https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: doubt about 'bool is_executing'

2021-07-29 Thread Gedare Bloom 
On Thu, Jul 29, 2021 at 12:56 AM Sebastian Huber
 wrote:
>
> On 28/07/2021 21:54, Gedare Bloom wrote:
> > Hello all,
> >
> > In most (all?) the SMP ports, we have in the CPU Context Control:
> >bool is_executing;
>
> Yes, all SMP ports need this. It is used to implement a TTAS lock in the
> context switch:
>
> https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details
>
> >
> > This variable often is accessed through assembly language (i.e.,
> > during the context switch), using something like
> > ARCH_CONTEXT_CONTROL_IS_EXECUTING_OFFSET. Unfortunately, the 'bool'
> > type is not standard, or rather its size is implementation-defined.  I
> > think it is generally an 8-bit value though for us. I see that the
> > riscv port uses explicitly a uint32_t so that's nice.
> >
> > I think we should replace 'bool' with uint8_t in the other ports that
> > are using byte-size accesses from assembly, just to be well-defined.
> > Most likely, this doesn't actually affect anything and I'm just a
> > little paranoid.
>
> Is the bool size and alignment not defined by the ABI? We don't have to
> use this type, we could also use an uint32_t or whatever. The convention
> is that a zero value is false, everything else is true.
>
I'm no expert, but I believe bool is defined by the compiler. There is
only a minimum size requirement of 1 byte, but no maximum size. So, we
do get consistent size, but we rely on gcc (and clang) to do the same
thing with bool and to not change their behavior in the future. This
is probably safe, but making assumptions about what compiler
implementers do can lead us into trouble.

I would switch to an explicitly sized type, either uint8_t or uint32_t
depending whether alignment may be more useful than potential 3B space
savings. Since we only deal with 32b and larger architectures with
data caches, the use of smaller types doesn't offer any great time
advantages.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: doubt about 'bool is_executing'

2021-07-29 Thread Sebastian Huber 

On 29/07/2021 15:01, Gedare Bloom wrote:

On Thu, Jul 29, 2021 at 12:56 AM Sebastian Huber
 wrote:


On 28/07/2021 21:54, Gedare Bloom wrote:

Hello all,

In most (all?) the SMP ports, we have in the CPU Context Control:
bool is_executing;


Yes, all SMP ports need this. It is used to implement a TTAS lock in the
context switch:

https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details



This variable often is accessed through assembly language (i.e.,
during the context switch), using something like
ARCH_CONTEXT_CONTROL_IS_EXECUTING_OFFSET. Unfortunately, the 'bool'
type is not standard, or rather its size is implementation-defined.  I
think it is generally an 8-bit value though for us. I see that the
riscv port uses explicitly a uint32_t so that's nice.

I think we should replace 'bool' with uint8_t in the other ports that
are using byte-size accesses from assembly, just to be well-defined.
Most likely, this doesn't actually affect anything and I'm just a
little paranoid.


Is the bool size and alignment not defined by the ABI? We don't have to
use this type, we could also use an uint32_t or whatever. The convention
is that a zero value is false, everything else is true.


I'm no expert, but I believe bool is defined by the compiler. There is
only a minimum size requirement of 1 byte, but no maximum size. So, we
do get consistent size, but we rely on gcc (and clang) to do the same
thing with bool and to not change their behavior in the future. This
is probably safe, but making assumptions about what compiler
implementers do can lead us into trouble.


It would be quite bad for interoperability if the bool type is not 
defined by the ABI.  For example:


https://developer.arm.com/documentation/ihi0055/b/



I would switch to an explicitly sized type, either uint8_t or uint32_t
depending whether alignment may be more useful than potential 3B space
savings. Since we only deal with 32b and larger architectures with
data caches, the use of smaller types doesn't offer any great time
advantages.


I am not against using another type, however, I have no time to do this.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems-utils: Change data type definition

2021-07-29 Thread Ryan Long 
Change typedef for ostream_guard to using.
---
 linkers/rtems-exeinfo.cpp| 2 +-
 tester/covoar/CoverageMapBase.cc | 2 +-
 tester/covoar/ReportsHtml.cc | 2 +-
 tester/covoar/ReportsText.cc | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index c9bf5b6..faa98a2 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -53,7 +53,7 @@
 #define kill(p,s) raise(s)
 #endif
 
-typedef rtems::utils::ostream_guard ostream_guard;
+using ostream_guard = rtems::utils::ostream_guard;
 
 namespace rld
 {
diff --git a/tester/covoar/CoverageMapBase.cc b/tester/covoar/CoverageMapBase.cc
index 4de9307..9966f73 100644
--- a/tester/covoar/CoverageMapBase.cc
+++ b/tester/covoar/CoverageMapBase.cc
@@ -16,7 +16,7 @@
 
 #include "CoverageMapBase.h"
 
-typedef rtems::utils::ostream_guard ostream_guard;
+using ostream_guard = rtems::utils::ostream_guard;
 
 namespace Coverage {
 
diff --git a/tester/covoar/ReportsHtml.cc b/tester/covoar/ReportsHtml.cc
index e276732..d68efd4 100644
--- a/tester/covoar/ReportsHtml.cc
+++ b/tester/covoar/ReportsHtml.cc
@@ -14,7 +14,7 @@
 #include "DesiredSymbols.h"
 #include "ObjdumpProcessor.h"
 
-typedef rtems::utils::ostream_guard ostream_guard;
+using ostream_guard = rtems::utils::ostream_guard;
 
 #if 0
 #define TABLE_HEADER_CLASS \
diff --git a/tester/covoar/ReportsText.cc b/tester/covoar/ReportsText.cc
index c4a5dbc..aba7e51 100644
--- a/tester/covoar/ReportsText.cc
+++ b/tester/covoar/ReportsText.cc
@@ -12,7 +12,7 @@
 
 #include 
 
-typedef rtems::utils::ostream_guard ostream_guard;
+using ostream_guard = rtems::utils::ostream_guard;
 
 namespace Coverage {
 
-- 
1.8.3.1

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

[PATCH 1/5] GcovData: Convert to C++

2021-07-29 Thread Ryan Long 
Change C-style code to C++
---
 tester/covoar/GcovData.cc | 317 --
 tester/covoar/GcovData.h  |  32 ++--
 tester/covoar/GcovFunctionData.cc | 287 --
 tester/covoar/GcovFunctionData.h  |  44 +++---
 4 files changed, 327 insertions(+), 353 deletions(-)

diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc
index e8b8573..800edae 100644
--- a/tester/covoar/GcovData.cc
+++ b/tester/covoar/GcovData.cc
@@ -1,9 +1,3 @@
-/*
- *  TODO: use strings instead of cstrings for reliability and saving memory
- *  TODO: use global buffers
- *
- */
-
 /*! @file GcovData.cc
  *  @brief GcovData Implementation
  *
@@ -34,62 +28,64 @@ namespace Gcov {
   {
   }
 
-  bool GcovData::readGcnoFile( const char* const  fileName )
+  bool GcovData::readGcnoFile( const std::string& fileName )
   {
-intstatus;
-FILE*  gcovFile;
-char*  tempString;
-char*  tempString2;
-char*  tempString3;
-
-if ( strlen(fileName) >= FILE_NAME_LENGTH ){
-  fprintf(
-stderr,
-"ERROR: File name is too long to be correctly stored: %u\n",
-(unsigned int) strlen(fileName)
-  );
+int   status;
+std::ifstream gcovFile;
+std::string   tempString;
+std::string   tempString2;
+std::string   tempString3;
+size_tindex;
+
+if ( fileName.length() >= FILE_NAME_LENGTH ) {
+  std::cerr << "ERROR: File name is too long to be correctly stored: "
+<< fileName.length() << std::endl;
   return false;
 }
-strcpy( gcnoFileName, fileName );
-strcpy( gcdaFileName, fileName );
-strcpy( textFileName, fileName );
-strcpy( cFileName, fileName );
-tempString = strstr( gcdaFileName,".gcno" );
-tempString2 = strstr( textFileName,".gcno" );
-tempString3 = strstr( cFileName,".gcno" );
-
-if ( (tempString == NULL) && (tempString2 == NULL) ){
-  fprintf(stderr, "ERROR: incorrect name of *.gcno file\n");
-}
-else
-{
-  strcpy( tempString, ".gcda"); // construct gcda file name
-  strcpy( tempString2, ".txt"); // construct report file name
-  strcpy( tempString3, ".c");   // construct source file name
+
+gcnoFileName = fileName;
+gcdaFileName = fileName;
+textFileName = fileName;
+cFileName= fileName;
+tempString   = gcdaFileName;
+tempString2  = textFileName;
+tempString3  = cFileName;
+
+index = tempString.find( ".gcno" );
+if ( index == std::string::npos ) {
+  std::cerr << "ERROR: incorrect name of *.gcno file" << std::endl;
+  return false;
+} else {
+  // construct gcda file name
+  tempString = tempString.replace( index, strlen( ".gcno" ), ".gcda" );
+
+  // construct report file name
+  tempString2 = tempString2.replace( index, strlen( ".gcno" ), ".txt" );
+
+  // construct source file name
+  tempString3 = tempString3.replace( index, strlen( ".gcno" ), ".c" );
 }
 
 // Debug message
-// fprintf( stderr, "Readning file: %s\n",  gcnoFileName);
+// std::cerr << "Reading file: " << gcnoFileName << std::endl;
 
 // Open the notes file.
-gcovFile = fopen( gcnoFileName, "r" );
+gcovFile.open( gcnoFileName );
 if ( !gcovFile ) {
-  fprintf( stderr, "Unable to open %s\n", gcnoFileName );
+  std::cerr << "Unable to open " << gcnoFileName << std::endl;
   return false;
 }
 
 // Read and validate the gcnoPreamble (magic, version, timestamp) from the 
file
 status = readFilePreamble( &gcnoPreamble, gcovFile, GCNO_MAGIC );
 if ( status <= 0 ){
-  fprintf( stderr, "Unable to read %s\n", gcnoFileName );
-  fclose( gcovFile );
+  std::cerr << "Unable to read " << gcnoFileName << std::endl;
   return false;
 }
 
 //Read all remaining frames from file
 while( readFrame(gcovFile) ){}
 
-fclose( gcovFile );
 return true;
   }
 
@@ -98,7 +94,7 @@ namespace Gcov {
   {
 gcov_preamble preamble;
 gcov_frame_header header;
-FILE* gcdaFile;
+std::ofstream gcdaFile;
 functions_iterator_t  currentFunction;
 arcs_iterator_t   currentArc;
 uint32_t  buffer;
@@ -109,10 +105,10 @@ namespace Gcov {
 uint64_t  llBuffer[4096];// TODO: Use common buffer
 gcov_statistics   objectStats;
 gcov_statistics   programStats;
-size_tstatus;
+long int  bytes_before;
 
 // Debug message
-// fprintf( stderr, "Writing file: %s\n",  gcdaFileName);
+//std::cerr << "Writing file: " <<  gcdaFileName << std::endl;
 
 // Lets clear counters sumators
 countersSum = 0;
@@ -120,9 +116,9 @@ namespace Gcov {
 countersFoundSum   = 0;
 
 // Open the data file.
-gcdaFile = fopen( gcdaFileName, "w" );
+gcdaFile.open( gcdaFileName );
 if ( !gcdaFile

RE: [PATCH 1/5] GcovData: Convert to C++

2021-07-29 Thread Ryan Long 
I'm not sending in five patches. I just wanted to send in the conversion to C++ 
separately from the reformatting of GcovData.

-Original Message-
From: Ryan Long  
Sent: Thursday, July 29, 2021 12:45 PM
To: devel@rtems.org
Cc: Ryan Long 
Subject: [PATCH 1/5] GcovData: Convert to C++

Change C-style code to C++
---
 tester/covoar/GcovData.cc | 317 --
 tester/covoar/GcovData.h  |  32 ++--
 tester/covoar/GcovFunctionData.cc | 287 --
 tester/covoar/GcovFunctionData.h  |  44 +++---
 4 files changed, 327 insertions(+), 353 deletions(-)

diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc index 
e8b8573..800edae 100644
--- a/tester/covoar/GcovData.cc
+++ b/tester/covoar/GcovData.cc
@@ -1,9 +1,3 @@
-/*
- *  TODO: use strings instead of cstrings for reliability and saving memory
- *  TODO: use global buffers
- *
- */
-
 /*! @file GcovData.cc
  *  @brief GcovData Implementation
  *
@@ -34,62 +28,64 @@ namespace Gcov {
   {
   }
 
-  bool GcovData::readGcnoFile( const char* const  fileName )
+  bool GcovData::readGcnoFile( const std::string& fileName )
   {
-intstatus;
-FILE*  gcovFile;
-char*  tempString;
-char*  tempString2;
-char*  tempString3;
-
-if ( strlen(fileName) >= FILE_NAME_LENGTH ){
-  fprintf(
-stderr,
-"ERROR: File name is too long to be correctly stored: %u\n",
-(unsigned int) strlen(fileName)
-  );
+int   status;
+std::ifstream gcovFile;
+std::string   tempString;
+std::string   tempString2;
+std::string   tempString3;
+size_tindex;
+
+if ( fileName.length() >= FILE_NAME_LENGTH ) {
+  std::cerr << "ERROR: File name is too long to be correctly stored: "
+<< fileName.length() << std::endl;
   return false;
 }
-strcpy( gcnoFileName, fileName );
-strcpy( gcdaFileName, fileName );
-strcpy( textFileName, fileName );
-strcpy( cFileName, fileName );
-tempString = strstr( gcdaFileName,".gcno" );
-tempString2 = strstr( textFileName,".gcno" );
-tempString3 = strstr( cFileName,".gcno" );
-
-if ( (tempString == NULL) && (tempString2 == NULL) ){
-  fprintf(stderr, "ERROR: incorrect name of *.gcno file\n");
-}
-else
-{
-  strcpy( tempString, ".gcda"); // construct gcda file name
-  strcpy( tempString2, ".txt"); // construct report file name
-  strcpy( tempString3, ".c");   // construct source file name
+
+gcnoFileName = fileName;
+gcdaFileName = fileName;
+textFileName = fileName;
+cFileName= fileName;
+tempString   = gcdaFileName;
+tempString2  = textFileName;
+tempString3  = cFileName;
+
+index = tempString.find( ".gcno" );
+if ( index == std::string::npos ) {
+  std::cerr << "ERROR: incorrect name of *.gcno file" << std::endl;
+  return false;
+} else {
+  // construct gcda file name
+  tempString = tempString.replace( index, strlen( ".gcno" ), 
+ ".gcda" );
+
+  // construct report file name
+  tempString2 = tempString2.replace( index, strlen( ".gcno" ), 
+ ".txt" );
+
+  // construct source file name
+  tempString3 = tempString3.replace( index, strlen( ".gcno" ), ".c" 
+ );
 }
 
 // Debug message
-// fprintf( stderr, "Readning file: %s\n",  gcnoFileName);
+// std::cerr << "Reading file: " << gcnoFileName << std::endl;
 
 // Open the notes file.
-gcovFile = fopen( gcnoFileName, "r" );
+gcovFile.open( gcnoFileName );
 if ( !gcovFile ) {
-  fprintf( stderr, "Unable to open %s\n", gcnoFileName );
+  std::cerr << "Unable to open " << gcnoFileName << std::endl;
   return false;
 }
 
 // Read and validate the gcnoPreamble (magic, version, timestamp) from the 
file
 status = readFilePreamble( &gcnoPreamble, gcovFile, GCNO_MAGIC );
 if ( status <= 0 ){
-  fprintf( stderr, "Unable to read %s\n", gcnoFileName );
-  fclose( gcovFile );
+  std::cerr << "Unable to read " << gcnoFileName << std::endl;
   return false;
 }
 
 //Read all remaining frames from file
 while( readFrame(gcovFile) ){}
 
-fclose( gcovFile );
 return true;
   }
 
@@ -98,7 +94,7 @@ namespace Gcov {
   {
 gcov_preamble preamble;
 gcov_frame_header header;
-FILE* gcdaFile;
+std::ofstream gcdaFile;
 functions_iterator_t  currentFunction;
 arcs_iterator_t   currentArc;
 uint32_t  buffer;
@@ -109,10 +105,10 @@ namespace Gcov {
 uint64_t  llBuffer[4096];// TODO: Use common buffer
 gcov_statistics   objectStats;
 gcov_statistics   programStats;
-size_tstatus;
+long int  bytes_before;
 
 // Debug message
-// fprintf( stderr, "Writing file: %s\n",  gcdaFileName);
+//std::cerr << "Writ

Re: [PATCH] rtems: Generate

2021-07-29 Thread Chris Johns 
On 29/7/21 10:59 pm, Sebastian Huber wrote:
> On 29/07/2021 14:51, Sebastian Huber wrote:
>> Change license to BSD-2-Clause according to file histories and
>> documentation re-licensing agreement.
>>
>> Place the group into the I/O Manager group.  Add all source files to the
>> group.
>>
>> Update #3899.
>> Update #3993.
> 
> It would be easy to add a chapter for this to the Classic API Guide (for 
> example
> "Kernel Character I/O Support"):
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> 

Looks good.

I think something should be said about the relationship of this interface to the
standard console and termios streams. Specifically they can use the same BSP
device and the output can become mixed if both are being used at the same time.

Should something be said about which calls can be used during interrupts? Also
concurrent calls on SMP system are not serialised.

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

Re: [PATCH] rtems-utils: Change data type definition

2021-07-29 Thread Chris Johns 
Why not use the namespace explicitly and avoid this shortening? Namespaces are
there to help.

With C++ I have a simple rule which is always use the namespace path where
possible. There are a few cases, for example in a class, a function or local
block where using an alias helps the formatting otherwise I avoid doing this.

I have found shortening like this can create churn in more complex cases where
the number of cases grows and the potential for clashes rises requiring some
pieces to change and that results in churn. In this case I need to remember the
local `ostream_guard` is actually the standard one and not something special
rather than just knowing this by reading it and in the more complex cases I need
to remember more and more mappings to understand the code.

Chris

On 29/7/21 11:34 pm, Ryan Long wrote:
> Change typedef for ostream_guard to using.
> ---
>  linkers/rtems-exeinfo.cpp| 2 +-
>  tester/covoar/CoverageMapBase.cc | 2 +-
>  tester/covoar/ReportsHtml.cc | 2 +-
>  tester/covoar/ReportsText.cc | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
> index c9bf5b6..faa98a2 100644
> --- a/linkers/rtems-exeinfo.cpp
> +++ b/linkers/rtems-exeinfo.cpp
> @@ -53,7 +53,7 @@
>  #define kill(p,s) raise(s)
>  #endif
>  
> -typedef rtems::utils::ostream_guard ostream_guard;
> +using ostream_guard = rtems::utils::ostream_guard;
>  
>  namespace rld
>  {
> diff --git a/tester/covoar/CoverageMapBase.cc 
> b/tester/covoar/CoverageMapBase.cc
> index 4de9307..9966f73 100644
> --- a/tester/covoar/CoverageMapBase.cc
> +++ b/tester/covoar/CoverageMapBase.cc
> @@ -16,7 +16,7 @@
>  
>  #include "CoverageMapBase.h"
>  
> -typedef rtems::utils::ostream_guard ostream_guard;
> +using ostream_guard = rtems::utils::ostream_guard;
>  
>  namespace Coverage {
>  
> diff --git a/tester/covoar/ReportsHtml.cc b/tester/covoar/ReportsHtml.cc
> index e276732..d68efd4 100644
> --- a/tester/covoar/ReportsHtml.cc
> +++ b/tester/covoar/ReportsHtml.cc
> @@ -14,7 +14,7 @@
>  #include "DesiredSymbols.h"
>  #include "ObjdumpProcessor.h"
>  
> -typedef rtems::utils::ostream_guard ostream_guard;
> +using ostream_guard = rtems::utils::ostream_guard;
>  
>  #if 0
>  #define TABLE_HEADER_CLASS \
> diff --git a/tester/covoar/ReportsText.cc b/tester/covoar/ReportsText.cc
> index c4a5dbc..aba7e51 100644
> --- a/tester/covoar/ReportsText.cc
> +++ b/tester/covoar/ReportsText.cc
> @@ -12,7 +12,7 @@
>  
>  #include 
>  
> -typedef rtems::utils::ostream_guard ostream_guard;
> +using ostream_guard = rtems::utils::ostream_guard;
>  
>  namespace Coverage {
>  
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: doubt about 'bool is_executing'

2021-07-29 Thread Chris Johns 
On 29/7/21 11:07 pm, Sebastian Huber wrote:
> On 29/07/2021 15:01, Gedare Bloom wrote:
> It would be quite bad for interoperability if the bool type is not defined by
> the ABI.  For example:
> 
> https://developer.arm.com/documentation/ihi0055/b/

https://yarchive.net/comp/linux/bool.html

Bool has been a sore point, even further back to the Alpha days.

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

Adding Xilinx QEMU to RSB

2021-07-29 Thread Alex White 
Hi,

I am trying to add Xilinx QEMU to rtems-source-builder for running RTEMS on 
MicroBlaze. It is located here: 
https://github.com/Xilinx/qemu/tree/branch/xilinx-v2020.2

I have successfully built it and installed it manually, but adding it as a 
"recipe" to RSB has given me issues.

Trying to copy from the existing QEMU configuration ended up giving me an error 
that the git submodules were not initialized. I then saw that building from git 
was not supported.

One thing I had success with was running the included scrips/archive-source.sh 
in Xilinx QEMU. That created a full tarball of everything needed to build. I 
was then able to refer to the local tarball in my Xilinx QEMU RSB configuration 
and successfully build. So it looks like an option would be hosting it 
somewhere and building the source tarball ourselves. This, however, seems like 
it might be overkill.

Is there a more elegant solution that anyone knows of? Maybe sb-set-builder 
could somehow initialize the git submodules at build time instead?

Thanks,

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

Error when trying to build llvm

2021-07-29 Thread Ida Delphine 
Hello everyone,
I have been trying to build llvm using the command
../source-builder/sb-set-builder --prefix=$HOME/development/rtems/6
6/rtems-llvm
Here's the error report
https://pastebin.com/vAXgwXMW
Please what am I missing?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] rtems: Generate

2021-07-29 Thread Sebastian Huber 
Change license to BSD-2-Clause according to file histories and
documentation re-licensing agreement.

Place the group into the I/O Manager group.  Add all source files to the
group.

Update #3899.
Update #3993.
---

v2:

* Add constraints.

* Reorder the directives.

 cpukit/include/rtems/bspIo.h| 364 +++-
 cpukit/libcsupport/src/getchark.c   |   2 +-
 cpukit/libcsupport/src/printk.c |   7 +-
 cpukit/libcsupport/src/printk_plugin.c  |   9 +-
 cpukit/libcsupport/src/putk.c   |   7 +-
 cpukit/libcsupport/src/rtems_put_char.c |   8 +
 cpukit/libcsupport/src/rtems_putc.c |   2 +-
 cpukit/libcsupport/src/vprintk.c|   7 +-
 8 files changed, 315 insertions(+), 91 deletions(-)

diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index ad196dfd34..6b0325932b 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -1,154 +1,364 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
- * @brief Interface to Kernel Print Methods
+ * @ingroup RTEMSAPIKernelCharIO
+ *
+ * @brief This header file provides the kernel character input/output support
+ *   API.
+ */
+
+/*
+ * Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
+ *
+ * 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 include file defines the interface to kernel print methods.
+ * 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.
  */
 
 /*
- *  COPYRIGHT (c) 1998 vale...@crf.canon.fr
- *  COPYRIGHT (c) 2011 On-Line Applications Research Corporation.
+ * This file is part of the RTEMS quality process and was automatically
+ * generated.  If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://www.rtems.org/bugs.html
+ *
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * https://docs.rtems.org
  */
 
+/* Generated from spec:/rtems/io/if/header-3 */
+
 #ifndef _RTEMS_BSPIO_H
 #define _RTEMS_BSPIO_H
 
-#include 
-
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/io/if/group-3 */
+
 /**
- * @defgroup BSPIO Kernel Print Support
+ * @defgroup RTEMSAPIKernelCharIO Kernel Character I/O Support
  *
- * @ingroup RTEMSAPIPrintSupport
+ * @ingroup RTEMSAPIClassicIO
  *
- * This module contains all methods and support related to providing
- * kernel level print support.
+ * @brief The kernel character input/output support is an extension of the @ref
+ *   RTEMSAPIClassicIO to input and output characters to a BSP defined device
+ *   using a polled and non-blocking implementation.
  *
- * The following variables below are declared as extern and
- * MUST be declared and initialized in each BSP. Using this indirect
- * function, the functionality in this group is tailored for the BSP.
- *
- *  - BSP_output_char
- *  - BSP_poll_char
+ * The directives may be used to print debug and test information.  The kernel
+ * character input/output support should work even if no Console Driver is
+ * configured, see #CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER.
  */
 
+/* Generated from spec:/rtems/io/if/bsp-output-char-function-type */
+
 /**
- * This type defines the prototype for the BSP provided

[PATCH] c-user: Add "Kernel Character I/O Support" chapter

2021-07-29 Thread Sebastian Huber 
Update #4482.
---
 c-user/fatal-error/directives.rst   |  10 +-
 c-user/index.rst|   1 +
 c-user/kernel-character-io/directives.rst   | 372 
 c-user/kernel-character-io/index.rst|  15 +
 c-user/kernel-character-io/introduction.rst |  69 
 c-user/rate-monotonic/directives.rst|   4 +-
 c-user/rate-monotonic/introduction.rst  |   2 +-
 7 files changed, 465 insertions(+), 8 deletions(-)
 create mode 100644 c-user/kernel-character-io/directives.rst
 create mode 100644 c-user/kernel-character-io/index.rst
 create mode 100644 c-user/kernel-character-io/introduction.rst

diff --git a/c-user/fatal-error/directives.rst 
b/c-user/fatal-error/directives.rst
index 98ce209..6aa4b20 100644
--- a/c-user/fatal-error/directives.rst
+++ b/c-user/fatal-error/directives.rst
@@ -116,10 +116,10 @@ Prints the message and invokes the fatal error handler.
 
 .. rubric:: DESCRIPTION:
 
-This directive prints a message via :c:func:`printk` specified by the ``fmt``
-parameter and optional parameters and then invokes the fatal error handler.
-The fatal source is set to :c:macro:`RTEMS_FATAL_SOURCE_PANIC`.  The fatal code
-is set to the value of the ``fmt`` parameter value.
+This directive prints a message via :ref:`InterfacePrintk` specified by the
+``fmt`` parameter and optional parameters and then invokes the fatal error
+handler.  The fatal source is set to :c:macro:`RTEMS_FATAL_SOURCE_PANIC`.  The
+fatal code is set to the value of the ``fmt`` parameter value.
 
 .. rubric:: CONSTRAINTS:
 
@@ -216,7 +216,7 @@ Prints the exception frame.
 .. rubric:: DESCRIPTION:
 
 The exception frame is printed in an architecture-dependent format using
-:c:func:`printk`.
+:ref:`InterfacePrintk`.
 
 .. Generated from spec:/rtems/fatal/if/source-text
 
diff --git a/c-user/index.rst b/c-user/index.rst
index 5cd87af..ae782f0 100644
--- a/c-user/index.rst
+++ b/c-user/index.rst
@@ -44,6 +44,7 @@ RTEMS Classic API Guide (|version|).
region/index
dual-ported-memory/index
io/index
+   kernel-character-io/index
fatal-error/index
board_support_packages
user-extensions/index
diff --git a/c-user/kernel-character-io/directives.rst 
b/c-user/kernel-character-io/directives.rst
new file mode 100644
index 000..f13010e
--- /dev/null
+++ b/c-user/kernel-character-io/directives.rst
@@ -0,0 +1,372 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+.. Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
+
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _KernelCharacterIOSupportDirectives:
+
+Directives
+==
+
+This section details the directives of the Kernel Character I/O Support. A
+subsection is dedicated to each of this manager's directives and lists the
+calling sequence, parameters, description, return values, and notes of the
+directive.
+
+.. Generated from spec:/rtems/io/if/putc
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: rtems_putc()
+
+.. _InterfaceRtemsPutc:
+
+rtems_putc()
+
+
+Outputs the character to the kernel character output device.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+void rtems_putc( char c );
+
+.. rubric:: PARAMETERS:
+
+``c``
+This parameter is the character to output.
+
+.. rubric:: DESCRIPTION:
+
+The directive outputs the character specified by ``c`` to the kernel character
+output device using the polled character output implementation provided by
+BSP_output_char.  The directive performs a character translation from ``NL`` to
+``CR`` followed by ``NR``.
+
+If the kernel character output device is concurrently accessed, then
+interleaved output may occur.
+
+.. rubric:: CONSTRAINTS:
+
+The following constraints apply to this directive:
+
+* The directive may be called from within any runtime context.
+
+* The directive will not cause the calling task to be preempted.
+
+.. Generated from spec:/rtems/io/if/put-char
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: rtems_put_char()
+
+.. _InterfaceRtemsPutChar:
+
+rtems_put_char()
+
+
+Puts the character using :ref:`InterfaceRtemsPutc`
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+void rtems_put_char( int c, void *unused );
+
+.. rubric:: PARAMETERS:
+
+``c``
+This parameter is the character to output.
+
+``unused`

Re: [PATCH] rtems: Generate

2021-07-29 Thread Sebastian Huber 

On 30/07/2021 00:54, Chris Johns wrote:

On 29/7/21 10:59 pm, Sebastian Huber wrote:

On 29/07/2021 14:51, Sebastian Huber wrote:

Change license to BSD-2-Clause according to file histories and
documentation re-licensing agreement.

Place the group into the I/O Manager group.  Add all source files to the
group.

Update #3899.
Update #3993.


It would be easy to add a chapter for this to the Classic API Guide (for example
"Kernel Character I/O Support"):

https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf



Looks good.

I think something should be said about the relationship of this interface to the
standard console and termios streams. Specifically they can use the same BSP
device and the output can become mixed if both are being used at the same time.

Should something be said about which calls can be used during interrupts? Also
concurrent calls on SMP system are not serialised.


I updated the proposal:

https://lists.rtems.org/pipermail/devel/2021-July/068657.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel