Re: [PATCH] build: Disable RTEMS_NETWORKING for some arch/bsp

[Gedare Bloom]

disable it for the sparc64 too please. thanks

On Tue, Oct 6, 2020 at 11:52 PM Sebastian Huber
 wrote:
>
> The old network stack is not supported on 64-bit targets.
> ---
>  spec/build/cpukit/optnet.yml | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/spec/build/cpukit/optnet.yml b/spec/build/cpukit/optnet.yml
> index 8678c8dbb8..7b0acf9083 100644
> --- a/spec/build/cpukit/optnet.yml
> +++ b/spec/build/cpukit/optnet.yml
> @@ -10,7 +10,17 @@ default: false
>  default-by-variant: []
>  description: |
>Enable the legacy TCP/IP network support
> -enabled-by: true
> +enabled-by:
> +  not:
> +- aarch64
> +- powerpc/qoriq_e6500_64
> +- riscv/rv64imac
> +- riscv/rv64imac_medany
> +- riscv/rv64imafd
> +- riscv/rv64imafd_medany
> +- riscv/rv64imafdc
> +- riscv/rv64imafdc_medany
> +- x86_64
>  links: []
>  name: RTEMS_NETWORKING
>  type: build
> --
> 2.26.2
>
> ___
> 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

[PATCH v2] build: Disable RTEMS_NETWORKING for some arch/bsp

[Sebastian Huber]

The old network stack is not supported on 64-bit targets.
---
v2:

Add sparc64 to black list.

 spec/build/cpukit/optnet.yml | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/spec/build/cpukit/optnet.yml b/spec/build/cpukit/optnet.yml
index 8678c8dbb8..8a223423ad 100644
--- a/spec/build/cpukit/optnet.yml
+++ b/spec/build/cpukit/optnet.yml
@@ -10,7 +10,18 @@ default: false
 default-by-variant: []
 description: |
   Enable the legacy TCP/IP network support
-enabled-by: true
+enabled-by:
+  not:
+  - aarch64
+  - powerpc/qoriq_e6500_64
+  - riscv/rv64imac
+  - riscv/rv64imac_medany
+  - riscv/rv64imafd
+  - riscv/rv64imafd_medany
+  - riscv/rv64imafdc
+  - riscv/rv64imafdc_medany
+  - sparc64
+  - x86_64
 links: []
 name: RTEMS_NETWORKING
 type: build
-- 
2.26.2

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

[PATCH 2/2] doxygen: Add "Generated from ..." comments

[Sebastian Huber]

Improve file header comment.

Update #3994.
---
 cpukit/doxygen/appl-config.h | 343 ++-
 1 file changed, 339 insertions(+), 4 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index eb9bf72abf..fe567b6e0f 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -28,12 +28,17 @@
  */
 
 /*
- * This file was automatically generated.  Do not edit it manually.
- * Please have a look at
+ * Do not manually edit this file.  It is part of the RTEMS quality process
+ * and was automatically generated.
  *
- * https://docs.rtems.org/branches/master/eng/req/howto.html
+ * If you find something that needs to be fixed or worded better please
+ * post a report to an RTEMS mailing list or raise a bug report:
+ *
+ * https://docs.rtems.org/branches/master/user/support/bugs.html
+ *
+ * For information on updating and regenerating please refer to:
  *
- * for information how to maintain and re-generate this file.
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
  */
 
 /**
@@ -42,6 +47,8 @@
  * @ingroup RTEMSAPI
  */
 
+/* Generated from spec:/acfg/if/group-bdbuf */
+
 /**
  * @defgroup RTEMSApplConfigBlockDeviceCacheConfiguration \
  *   Block Device Cache Configuration
@@ -54,6 +61,8 @@
  * @{
  */
 
+/* Generated from spec:/acfg/if/appl-needs-libblock */
+
 /**
  * @brief This configuration option is a boolean feature define.
  *
@@ -71,6 +80,8 @@
  */
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+/* Generated from spec:/acfg/if/bdbuf-buffer-max-size */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -92,6 +103,8 @@
  */
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE
 
+/* Generated from spec:/acfg/if/bdbuf-buffer-min-size */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -108,6 +121,8 @@
  */
 #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE
 
+/* Generated from spec:/acfg/if/bdbuf-cache-memory-size */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -124,6 +139,8 @@
  */
 #define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
 
+/* Generated from spec:/acfg/if/bdbuf-max-read-ahead-blocks */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -145,6 +162,8 @@
  */
 #define CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS
 
+/* Generated from spec:/acfg/if/bdbuf-max-write-blocks */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -161,6 +180,8 @@
  */
 #define CONFIGURE_BDBUF_MAX_WRITE_BLOCKS
 
+/* Generated from spec:/acfg/if/bdbuf-read-ahead-task-priority */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -175,6 +196,8 @@
  */
 #define CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY
 
+/* Generated from spec:/acfg/if/bdbuf-task-stack-size */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -202,6 +225,8 @@
  */
 #define CONFIGURE_BDBUF_TASK_STACK_SIZE
 
+/* Generated from spec:/acfg/if/bdbuf-swapout-block-hold */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -218,6 +243,8 @@
  */
 #define CONFIGURE_SWAPOUT_BLOCK_HOLD
 
+/* Generated from spec:/acfg/if/bdbuf-swapout-swap-period */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -234,6 +261,8 @@
  */
 #define CONFIGURE_SWAPOUT_SWAP_PERIOD
 
+/* Generated from spec:/acfg/if/bdbuf-swapout-task-priority */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -248,6 +277,8 @@
  */
 #define CONFIGURE_SWAPOUT_TASK_PRIORITY
 
+/* Generated from spec:/acfg/if/bdbuf-swapout-worker-tasks */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -264,6 +295,8 @@
  */
 #define CONFIGURE_SWAPOUT_WORKER_TASKS
 
+/* Generated from spec:/acfg/if/bdbuf-swapout-worker-taskp-riority */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -281,6 +314,8 @@
 
 /** @} */
 
+/* Generated from spec:/acfg/if/group-bsp */
+
 /**
  * @defgroup RTEMSApplConfigBSPRelatedConfigurationOptions \
  *   BSP Related Configuration Options
@@ -295,6 +330,8 @@
  * @{
  */
 
+/* Generated from spec:/acfg/if/bsp-idle-task-body */
+
 /**
  * @brief This configuration option is an initializer define.
  *
@@ -321,6 +358,8 @@
  */
 #define BSP_IDLE_TASK_BODY
 
+/* Generated from spec:/acfg/if/bsp-idle-task-stack-size */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -351,6 +390,8 @@
  */
 #define BSP_IDLE_TASK_STACK_SIZE
 
+/* Generated from spec:/acfg/if/bsp-initial-extension */
+
 /**
  * @brief This configuration option is an initializer define.
  *
@@ -376,6 +417,8 @@
  */
 #define BSP_INITIAL_EXTENSION
 
+/* Generated from spec:/acfg/if/bsp-interrupt-stack-size */
+
 /**
  * @brief This configuration option is an integer define.
  *
@@ -408,6 +451,8 @@
  */
 #define BSP_INTERRUPT_STACK_SIZE
 
+/* Generated from spec:/acfg/if/bsp-prerequisite-drivers */
+
 /**
  * @brief This configuration option is an initializer define.
  *
@@ -434,6 +479,8 @@
  *

[PATCH 1/2] rtems: Add "Generated from ..." comments

[Sebastian Huber]

Improve file header comment.

Update #3993.
---
 cpukit/include/rtems.h | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index cda2bd5b24..9b0765efda 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -35,14 +35,21 @@
  */
 
 /*
- * This file was automatically generated.  Do not edit it manually.
- * Please have a look at
+ * Do not manually edit this file.  It is part of the RTEMS quality process
+ * and was automatically generated.
  *
- * https://docs.rtems.org/branches/master/eng/req/howto.html
+ * If you find something that needs to be fixed or worded better please
+ * post a report to an RTEMS mailing list or raise a bug report:
+ *
+ * https://docs.rtems.org/branches/master/user/support/bugs.html
+ *
+ * For information on updating and regenerating please refer to:
  *
- * for information how to maintain and re-generate this file.
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
  */
 
+/* Generated from spec:/rtems/if/header */
+
 #ifndef _RTEMS_H
 #define _RTEMS_H
 
@@ -79,6 +86,8 @@
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/if/group */
+
 /**
  * @defgroup RTEMSAPIClassic Classic
  *
-- 
2.26.2

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

[PATCH v2] rtems: Generate

[Sebastian Huber]

The manager documentation is a consolidation of the comments in Doxygen
markup and the documentation sources in Sphinx markup.  The
documentation was transfered to interface specification items.  This
header file was generated from the items by a script.

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

Update #3899.
Update #3993.
---
v2:

* Add "Generated from ..." comments.

* Improve file header comment.

 cpukit/include/rtems/io.h | 501 --
 1 file changed, 378 insertions(+), 123 deletions(-)

diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
index 67364df280..4cac884756 100644
--- a/cpukit/include/rtems/io.h
+++ b/cpukit/include/rtems/io.h
@@ -1,228 +1,483 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
- * @brief Classic Input/Output Manager API
- * 
- * This file emulates the old Classic RTEMS IO manager directives
- * which register names using the in-memory filesystem.
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This header file defines the IO Manager API.
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 1988, 2008 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 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) 1989-2008.
- *  On-Line Applications Research Corporation (OAR).
+ * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ *
+ * https://docs.rtems.org/branches/master/user/support/bugs.html
+ *
+ * For information on updating and regenerating please refer to:
  *
- *  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/branches/master/eng/req/howto.html
  */
 
+/* Generated from spec:/rtems/io/if/header */
+
 #ifndef _RTEMS_IO_H
 #define _RTEMS_IO_H
 
+#include 
 #include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/io/if/group */
+
 /**
- * @defgroup ClassicIO Input/Output
+ * @defgroup RTEMSAPIClassicIO I/O Manager
  *
  * @ingroup RTEMSAPIClassic
  *
+ * @brief The Input/Output (I/O) Manager provides a well-defined mechanism for
+ *   accessing device drivers and a structured methodology for organizing
+ *   device drivers.
  */
-/**@{**/
 
-typedef uint32_t rtems_device_major_number;
+/* Generated from spec:/rtems/io/if/device-minor-number */
 
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This integer type represents the minor number of devices.
+ *
+ * The minor number of devices is managed by the device driver.
+ */
 typedef uint32_t rtems_device_minor_number;
 
+/* Generated from spec:/rtems/io/if/device-major-number */
+
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This integer type represents the major number of devices.
+ *
+ * The major number of a device is determined by rtems_io_register_driver() and
+ * the application configuration (see #CONFIGURE_MAXIMUM_DRIVERS) .
+ */
+typedef uint32_t rtems_device_major_number;
+
+/* Generated from spec:/rtems/io/if/device-driver */
+
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This type shall be used in device driver entry declarations and
+ *   definitions.
+ *
+ * Device driver entries return an #rtems_status_code status code. This type
+ * definition helps to document device driver entries in the source code.
+ */
 typedef rtems_status_code rtems_device_driver;
 
-typedef rtems_device_driver (*rt

Re: Legacy networking stack removal

[Peter Dufault]

> On Oct 7, 2020, at 01:43 , Sebastian Huber 
>  wrote:
> 
> On 07/10/2020 02:07, Chris Johns wrote:
> 
>> On 7/10/20 10:21 am, Joel Sherrill wrote:
>>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns >> > wrote:
>>> 
>>> What is the life span of the legacy stack in rtems.git? I see this 
>>> software as a
>>> liability.
>>> 
>>> I'd love it to be a sliver over autoconf.
>> Sounds like a plan. I have created a task against the 6.1 milestone:
>> 
>> https://devel.rtems.org/ticket/4126
>> 
>>> I think it is hard to actively encourage our users to use libbsd if we 
>>> have an
>>> enable or waf equivalent at hand in rtems.git.
>>> 
>>> I'd love it to go in its own separate repo. Is that at all possible? What's
>>> required?
>> I suggest we move it to a top level repo with the network demo code and then 
>> see
>> what happens. In theory it should be easy to build with rtems_waf.
>> 
>> The remaining fragments of code can be removed from the BSP files and maybe
>> moved to a header file in the new repo once we have made the split.
>> 
>> The change will break existing users but I think we need to make the change.
>> Users who still depend on this stack need to either post here and make us 
>> aware,
>> post fixes or directly contact you, me or others for support options.
> Maintaining or removing the old network stack is both fine for me. Moving the 
> stuff out of the RTEMS repository is a bit of work.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

The footprint is larger.  I forget exactly which board I was evaluating but I 
couldn't always use the "libbsd" stack and made it conditional.

I didn't spend much time trying to reduce the footprint.  Maybe if I'd removed 
some of the shell commands it would have been smaller.

An alternative is "lwIP".  I don't have experience with that.  Maybe "lwIP" and 
"libbsd" should be the recommended solutions.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.



signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Count (rtems-bsps, autoconf, and waf)

[Joel Sherrill]

On Wed, Oct 7, 2020 at 1:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Here is the difference:
>
> --- old 2020-10-07 08:01:12.249050086 +0200
> +++ new 2020-10-07 08:00:51.436897826 +0200
> @@ -1,6 +1,7 @@
> +aarch64/a53_ilp32_qemu
> +aarch64/a53_lp64_qemu
>   arm/altcycv_devkit
>   arm/atsamv
> -arm/bbxm
>   arm/beagleboardorig
>   arm/beagleboardxm
>   arm/beagleboneblack
> @@ -95,7 +96,6 @@
>   mips/rbtx4938
>   moxie/moxiesim
>   nios2/nios2_iss
> -no_cpu/no_bsp
>   or1k/generic_or1k
>   powerpc/beatnik
>   powerpc/br_uid
> @@ -143,25 +142,17 @@
>   riscv/grv32imac
>   riscv/grv32imafdc
>   riscv/rv32i
> -riscv/rv32i_clang
>   riscv/rv32iac
> -riscv/rv32iac_clang
>   riscv/rv32im
> -riscv/rv32im_clang
>   riscv/rv32imac
> -riscv/rv32imac_clang
>   riscv/rv32imafc
> -riscv/rv32imafc_clang
>   riscv/rv32imafd
> -riscv/rv32imafd_clang
>   riscv/rv32imafdc
> -riscv/rv32imafdc_clang
>   riscv/rv64imac
>   riscv/rv64imac_medany
>   riscv/rv64imafd
>   riscv/rv64imafd_medany
>   riscv/rv64imafdc
> -riscv/rv64imafdc_clang
>   riscv/rv64imafdc_medany
>   sh/gensh1
>   sh/gensh2
>

Thanks. I really didn't think there was going to be a problem
but it needed to be explained.

How is clang vs gcc done in waf?

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

Re: BSP Count (rtems-bsps, autoconf, and waf)

[Sebastian Huber]

On 07/10/2020 14:57, Joel Sherrill wrote:


How is clang vs gcc done in waf?


It is a configuration option:

# Selects the compiler used to build the BSP (allowed values are "gcc" and
# "clang").  Please note that the values of some options depend on the 
compiler

# selection and changing the compiler may lead to unpredictable behaviour if
# these options are not adjusted as well.  Use the --rtems-compiler 
command line

# option to get the default values for a particular compiler via
# ./waf bsp_defaults.
COMPILER = gcc

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

Re: BSP Count (rtems-bsps, autoconf, and waf)

[Joel Sherrill]

On Wed, Oct 7, 2020 at 8:18 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 07/10/2020 14:57, Joel Sherrill wrote:
>
> > How is clang vs gcc done in waf?
>
> It is a configuration option:
>
> # Selects the compiler used to build the BSP (allowed values are "gcc" and
> # "clang").  Please note that the values of some options depend on the
> compiler
> # selection and changing the compiler may lead to unpredictable behaviour
> if
> # these options are not adjusted as well.  Use the --rtems-compiler
> command line
> # option to get the default values for a particular compiler via
> # ./waf bsp_defaults.
> COMPILER = gcc
>

Thanks. Just playing with the options, it looks like it lets you set clang
on any BSP even though that isn't going to work.

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

Re: [PATCH v2] build: Disable RTEMS_NETWORKING for some arch/bsp

[Joel Sherrill]

This seems reasonable until we can remove it.

On Wed, Oct 7, 2020 at 2:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The old network stack is not supported on 64-bit targets.
> ---
> v2:
>
> Add sparc64 to black list.
>
>  spec/build/cpukit/optnet.yml | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/spec/build/cpukit/optnet.yml b/spec/build/cpukit/optnet.yml
> index 8678c8dbb8..8a223423ad 100644
> --- a/spec/build/cpukit/optnet.yml
> +++ b/spec/build/cpukit/optnet.yml
> @@ -10,7 +10,18 @@ default: false
>  default-by-variant: []
>  description: |
>Enable the legacy TCP/IP network support
> -enabled-by: true
> +enabled-by:
> +  not:
> +  - aarch64
> +  - powerpc/qoriq_e6500_64
> +  - riscv/rv64imac
> +  - riscv/rv64imac_medany
> +  - riscv/rv64imafd
> +  - riscv/rv64imafd_medany
> +  - riscv/rv64imafdc
> +  - riscv/rv64imafdc_medany
> +  - sparc64
> +  - x86_64
>  links: []
>  name: RTEMS_NETWORKING
>  type: build
> --
> 2.26.2
>
> ___
> 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: Legacy networking stack removal

[Sebastian Huber]

On 07/10/2020 13:29, Peter Dufault wrote:


On Oct 7, 2020, at 01:43 , Sebastian Huber  
wrote:

On 07/10/2020 02:07, Chris Johns wrote:


On 7/10/20 10:21 am, Joel Sherrill wrote:

On Tue, Oct 6, 2020, 6:16 PM Chris Johns mailto:chr...@rtems.org>> wrote:

 What is the life span of the legacy stack in rtems.git? I see this 
software as a
 liability.

I'd love it to be a sliver over autoconf.

Sounds like a plan. I have created a task against the 6.1 milestone:

https://devel.rtems.org/ticket/4126


 I think it is hard to actively encourage our users to use libbsd if we 
have an
 enable or waf equivalent at hand in rtems.git.

I'd love it to go in its own separate repo. Is that at all possible? What's
required?

I suggest we move it to a top level repo with the network demo code and then see
what happens. In theory it should be easy to build with rtems_waf.

The remaining fragments of code can be removed from the BSP files and maybe
moved to a header file in the new repo once we have made the split.

The change will break existing users but I think we need to make the change.
Users who still depend on this stack need to either post here and make us aware,
post fixes or directly contact you, me or others for support options.

Maintaining or removing the old network stack is both fine for me. Moving the 
stuff out of the RTEMS repository is a bit of work.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

The footprint is larger.  I forget exactly which board I was evaluating but I couldn't 
always use the "libbsd" stack and made it conditional.

I didn't spend much time trying to reduce the footprint.  Maybe if I'd removed 
some of the shell commands it would have been smaller.

An alternative is "lwIP".  I don't have experience with that.  Maybe "lwIP" and 
"libbsd" should be the recommended solutions.
Yes, the libbsd footprint is considerably larger. It has also a lot of 
features. For the low-end endpoint devices lwIP is probably the better 
choice.

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

BSP Build Sweep (7 Oct 2020)

[Joel Sherrill]

Hi

Results from the sweep that just finished. It is clear that since this
takes ~42 hours to run that it tends to have failures which were fixed in
the almost 2 days it takes for this to finish.

Total:   1744 all-bsps-log.txt
Passed:  1657
Failed:  87

Failed autoconf:  60
Failed waf:   27
Failed (NOSMP):   67

I attached the complete summary log and the failed log. It looks like the
sweep should ignore the risv*_clang BSPs in autoconf, x86_64 failures that
Sebastian says should be fixed, and raspberry pi failures which are because
Pi doesn't support SMP.  That still leaves 43 failures to account for.

About half of those appear to be a build failure in griscv BSPs (#4128).
Others are scattered across arm.

I'm going to hold off starting another sweep until later in the day to give
anyone a chance to quickly poke at them.

Thanks.

--joel
FAILED (2)  autoconf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm lm3s3749 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm lpc2362 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm lpc2362 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm lpc2362 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (1)  waf build of arm lpc2362 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (1)  waf build of arm lpc23xx_tli800 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm lpc23xx_tli800 (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm lpc32xx_mzx_stage_1 (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm lpc32xx_mzx_stage_1 
(NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/DEBUG/NOPROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of arm raspberrypi (SMP/NOMP/NODEBUG/NOPROFILE)
FAILED (1)  waf build of arm raspberrypi (SMP/NOMP/NODEBUG/NOPROFILE)
FAILED (2)  autoconf build of riscv griscv (SMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv griscv (SMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv griscv (SMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv griscv (SMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv griscv (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv griscv (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv griscv (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv griscv (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32i (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32i (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32i (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32i (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32im (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32im (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32im (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32im (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imac (SMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imac (SMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imac (SMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imac (SMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imac (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imac (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imac (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imac (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imafdc (SMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imafdc (SMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imafdc (SMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imafdc (SMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imafdc (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imafdc (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv grv32imafdc (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (1)  waf build of riscv grv32imafdc (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv rv32i_clang (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv rv32i_clang (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of riscv rv32i_clang (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  autoconf build of riscv rv32i_clang (NOSMP/NOMP/NODEBUG/NOPROFILE)
FAILED (2)  autoconf build of riscv rv32iac_clang (NOSMP/NOMP/DEBUG/PROFILE)
FAILED (2)  autoconf build of riscv rv32iac_clang (NOSMP/NOMP/DEBUG/NOPROFILE)
FAILED (2)  autoconf build of riscv rv32iac_clang (NOSMP/NOMP/NODEBUG/PROFILE)
FAILED (2)  a

Re: BSP Build Sweep (7 Oct 2020)

[Sebastian Huber]

On 07/10/2020 15:54, Joel Sherrill wrote:

x86_64 failures that Sebastian says should be fixed,

Someone has to say yes or no to the patch.

and raspberry pi failures which are because Pi doesn't support SMP.

This should be fixed.

That still leaves 43 failures to account for.

About half of those appear to be a build failure in griscv BSPs (#4128).

I don't have time to fix this today.

Others are scattered across arm.

This should be already fixed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Legacy networking stack removal

[Joel Sherrill]

On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault  wrote:

>
>
> > On Oct 7, 2020, at 01:43 , Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > On 07/10/2020 02:07, Chris Johns wrote:
> >
> >> On 7/10/20 10:21 am, Joel Sherrill wrote:
> >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns  >>> > wrote:
> >>>
> >>> What is the life span of the legacy stack in rtems.git? I see this
> software as a
> >>> liability.
> >>>
> >>> I'd love it to be a sliver over autoconf.
> >> Sounds like a plan. I have created a task against the 6.1 milestone:
> >>
> >> https://devel.rtems.org/ticket/4126
> >>
> >>> I think it is hard to actively encourage our users to use libbsd
> if we have an
> >>> enable or waf equivalent at hand in rtems.git.
> >>>
> >>> I'd love it to go in its own separate repo. Is that at all possible?
> What's
> >>> required?
> >> I suggest we move it to a top level repo with the network demo code and
> then see
> >> what happens. In theory it should be easy to build with rtems_waf.
> >>
> >> The remaining fragments of code can be removed from the BSP files and
> maybe
> >> moved to a header file in the new repo once we have made the split.
> >>
> >> The change will break existing users but I think we need to make the
> change.
> >> Users who still depend on this stack need to either post here and make
> us aware,
> >> post fixes or directly contact you, me or others for support options.
> > Maintaining or removing the old network stack is both fine for me.
> Moving the stuff out of the RTEMS repository is a bit of work.
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> The footprint is larger.  I forget exactly which board I was evaluating
> but I couldn't always use the "libbsd" stack and made it conditional.
>

The footprint is an issue but even on boards with enough memory, there will
be effort required to move to the new stack.


>
> I didn't spend much time trying to reduce the footprint.  Maybe if I'd
> removed some of the shell commands it would have been smaller.
>

It would be interesting to see what the smallest application that has
libbsd TCP/IP IPV4 in it could be. The old stack has a netdemo with a
couple of echo tasks which could come in around 250-300K code space. And
usually you didn't need a huge amount of buffers but the interfaces were
usually much slower. Even 100BaseT can require a lot of memory for
buffering.

I recall adding a way to tune the default buffering per socket because I
helped with an app where it required about 1MB per socket by default.

The old stack is just that old -- it was optimized for older hardware --
but it hasn't kept up with any potential fixes and as Chris pointed out
there is now a known issue against Windows. I'd like to encourage people to
move but unfortunately know some may want to do the risk calculation and
keep using it.

Chris and I chatted about this. We thought removing it from rtems proper
and just creating another repo with just the files removed in their current
layout is the minimum legwork to make it possible to revive it if someone
asks. But we wouldn't touch it more unless someone REALLY wants it revived.


> An alternative is "lwIP".  I don't have experience with that.  Maybe
> "lwIP" and "libbsd" should be the recommended solutions.
>

lwIP may be a good option for many but it still leaves you with a driver
issue. It does solve the low memory issue and hopefully has enough features
for the applications on lower end hardware.

Unfortunately, this is a case where the RTEMS core developers are too nice.
We don't want to leave users wanting. Many projects would have killed the
old stack before now.  And I think it is long overdue for us. :)

I am thinking 4-6 weeks after the transition from autoconf to waf, the
stack should come out. With any luck, this will be in December.  Moving to
waf is an ideal time to clean cruft and being just after the 5 release, we
left things in for that last release if that's what the outcome is.

--joel


> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Build Sweep (7 Oct 2020)

[Joel Sherrill]

On Wed, Oct 7, 2020 at 9:01 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 07/10/2020 15:54, Joel Sherrill wrote:
> > x86_64 failures that Sebastian says should be fixed,
> Someone has to say yes or no to the patch.
> > and raspberry pi failures which are because Pi doesn't support SMP.
> This should be fixed.
> > That still leaves 43 failures to account for.
> >
> > About half of those appear to be a build failure in griscv BSPs (#4128).
> I don't have time to fix this today.
>

Any idea what should be done for this fatal error then? It looks like a
simple change but a matter of knowing what to do.

Is the compiler suggestion correct? I'm happy to make the change and
restart a build before the end of the day.

./../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:
In function 'grlib_clock_initialize':
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:174:10:
warning: implicit declaration of function 'grlib_irqmp_has_timestamp'
[-Wimplicit-function-declaration]
  174 | if (!grlib_irqmp_has_timestamp(irqmp_ts)) {
  |  ^
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:174:10:
warning: nested extern declaration of 'grlib_irqmp_has_timestamp'
[-Wnested-externs]
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:175:17:
error: 'GRLIB_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT' undeclared (first use
in this function); did you mean
'LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT'?
  175 |   bsp_fatal(GRLIB_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
  | ^~~~
  | LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT
../../../../../../../../rtems/c/src/lib/libbsp/riscv/griscv/../../../../../../bsps/riscv/griscv/clock/clockdrv.c:175:17:
note: each undeclared identifier is reported only once for each function it
appears in
gmake[6]: *** [clockdrv.o] Error 1


> > Others are scattered across arm.
> This should be already fixed.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Legacy networking stack removal

[Christian Mauderer]

On 07/10/2020 16:12, Joel Sherrill wrote:
> 
> 
> On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault  > wrote:
> 
> 
> 
> > On Oct 7, 2020, at 01:43 , Sebastian Huber
>  > wrote:
> >
> > On 07/10/2020 02:07, Chris Johns wrote:
> >
> >> On 7/10/20 10:21 am, Joel Sherrill wrote:
> >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns  
> >>> >> wrote:
> >>>
> >>>     What is the life span of the legacy stack in rtems.git? I
> see this software as a
> >>>     liability.
> >>>
> >>> I'd love it to be a sliver over autoconf.
> >> Sounds like a plan. I have created a task against the 6.1 milestone:
> >>
> >> https://devel.rtems.org/ticket/4126
> >>
> >>>     I think it is hard to actively encourage our users to use
> libbsd if we have an
> >>>     enable or waf equivalent at hand in rtems.git.
> >>>
> >>> I'd love it to go in its own separate repo. Is that at all
> possible? What's
> >>> required?
> >> I suggest we move it to a top level repo with the network demo
> code and then see
> >> what happens. In theory it should be easy to build with rtems_waf.
> >>
> >> The remaining fragments of code can be removed from the BSP files
> and maybe
> >> moved to a header file in the new repo once we have made the split.
> >>
> >> The change will break existing users but I think we need to make
> the change.
> >> Users who still depend on this stack need to either post here and
> make us aware,
> >> post fixes or directly contact you, me or others for support options.
> > Maintaining or removing the old network stack is both fine for me.
> Moving the stuff out of the RTEMS repository is a bit of work.
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> 
> The footprint is larger.  I forget exactly which board I was
> evaluating but I couldn't always use the "libbsd" stack and made it
> conditional.
> 
> 
> The footprint is an issue but even on boards with enough memory, there
> will be effort required to move to the new stack. 
>  
> 
> 
> I didn't spend much time trying to reduce the footprint.  Maybe if
> I'd removed some of the shell commands it would have been smaller.
> 
> 
> It would be interesting to see what the smallest application that has
> libbsd TCP/IP IPV4 in it could be. The old stack has a netdemo with a
> couple of echo tasks which could come in around 250-300K code space. And
> usually you didn't need a huge amount of buffers but the interfaces were
> usually much slower. Even 100BaseT can require a lot of memory for
> buffering. 

Note that you can reduce the footprint a bit by using the minimal
buildset. It throws out stuff like IPv6 (who needs such modern stuff
anyway?). But you will currently not reach the old stack. Maybe we
should work towards throwing out more stuff out of the minimal buildset
to make it smaller ;-)

> 
> I recall adding a way to tune the default buffering per socket because I
> helped with an app where it required about 1MB per socket by default.
> 
> The old stack is just that old -- it was optimized for older hardware --
> but it hasn't kept up with any potential fixes and as Chris pointed out
> there is now a known issue against Windows. I'd like to encourage people
> to move but unfortunately know some may want to do the risk calculation
> and keep using it. 
> 
> Chris and I chatted about this. We thought removing it from rtems proper
> and just creating another repo with just the files removed in their
> current layout is the minimum legwork to make it possible to revive it
> if someone asks. But we wouldn't touch it more unless someone REALLY
> wants it revived.
>
> 
> An alternative is "lwIP".  I don't have experience with that.  Maybe
> "lwIP" and "libbsd" should be the recommended solutions.
> 
> 
> lwIP may be a good option for many but it still leaves you with a driver
> issue. It does solve the low memory issue and hopefully has enough
> features for the applications on lower end hardware.

Maybe the next time someone has a funded project into the direction of
lwIP we should try to create a package repo so it can be build without a
lot of effort.

> 
> Unfortunately, this is a case where the RTEMS core developers are too
> nice. We don't want to leave users wanting. Many projects would have
> killed the old stack before now.  And I think it is long overdue for us. :)

Do you ask us to be a bit less nice to users? I'll have to create a link
so that I can reference this statement the next time we discuss a change
that could break something for users ;-)

Best regards

Christian

> 
> I am thinking 4-6 weeks after the

Re: [PATCH v2] rtems: Generate

[Gedare Bloom]

it would be good to review the generated doxygen. some comments below.
overall a positive improvement.

On Wed, Oct 7, 2020 at 4:19 AM Sebastian Huber
 wrote:
>
> The manager documentation is a consolidation of the comments in Doxygen
> markup and the documentation sources in Sphinx markup.  The
> documentation was transfered to interface specification items.  This
> header file was generated from the items by a script.
>
> Change license to BSD-2-Clause according to file histories and
> documentation re-licensing agreement.
>
> Update #3899.
> Update #3993.
> ---
> v2:
>
> * Add "Generated from ..." comments.
>
> * Improve file header comment.
>
>  cpukit/include/rtems/io.h | 501 --
>  1 file changed, 378 insertions(+), 123 deletions(-)
>
> diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
> index 67364df280..4cac884756 100644
> --- a/cpukit/include/rtems/io.h
> +++ b/cpukit/include/rtems/io.h
> @@ -1,228 +1,483 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> - * @brief Classic Input/Output Manager API
> - *
> - * This file emulates the old Classic RTEMS IO manager directives
> - * which register names using the in-memory filesystem.
> + * @ingroup RTEMSAPIClassicIO
> + *
> + * @brief This header file defines the IO Manager API.
> + */
> +
> +/*
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + * Copyright (C) 1988, 2008 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 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) 1989-2008.
> - *  On-Line Applications Research Corporation (OAR).
> + * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
> + *
> + * https://docs.rtems.org/branches/master/user/support/bugs.html
> + *
> + * For information on updating and regenerating please refer to:
>   *
> - *  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/branches/master/eng/req/howto.html
>   */
>
> +/* Generated from spec:/rtems/io/if/header */
> +
>  #ifndef _RTEMS_IO_H
>  #define _RTEMS_IO_H
>
> +#include 
>  #include 
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
>
> +/* Generated from spec:/rtems/io/if/group */
> +
>  /**
> - * @defgroup ClassicIO Input/Output
> + * @defgroup RTEMSAPIClassicIO I/O Manager
>   *
>   * @ingroup RTEMSAPIClassic
>   *
> + * @brief The Input/Output (I/O) Manager provides a well-defined mechanism 
> for
> + *   accessing device drivers and a structured methodology for organizing
> + *   device drivers.
>   */
> -/**@{**/
>
> -typedef uint32_t rtems_device_major_number;
> +/* Generated from spec:/rtems/io/if/device-minor-number */
>
> +/**
> + * @ingroup RTEMSAPIClassicIO
> + *
> + * @brief This integer type represents the minor number of devices.
> + *
> + * The minor number of devices is managed by the device driver.
> + */
>  typedef uint32_t rtems_device_minor_number;
>
> +/* Generated from spec:/rtems/io/if/device-major-number */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIO
> + *
> + * @brief This integer type represents the major number of devices.
> + *
> + * The major number of a device is determined by rtems_io_register_driver() 
> and
> + * the application configuration (see #CONFIGURE_MAXIMUM_DRIVERS) .
> + */
> +typedef uint32_t rtems_device_major_number;
> +
> +/* Generated from

Re: Legacy networking stack removal

[Joel Sherrill]

On Wed, Oct 7, 2020 at 10:12 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

>
> On 07/10/2020 16:12, Joel Sherrill wrote:
> >
> >
> > On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault  > > wrote:
> >
> >
> >
> > > On Oct 7, 2020, at 01:43 , Sebastian Huber
> >  > > wrote:
> > >
> > > On 07/10/2020 02:07, Chris Johns wrote:
> > >
> > >> On 7/10/20 10:21 am, Joel Sherrill wrote:
> > >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns  > 
> > >>> >> wrote:
> > >>>
> > >>> What is the life span of the legacy stack in rtems.git? I
> > see this software as a
> > >>> liability.
> > >>>
> > >>> I'd love it to be a sliver over autoconf.
> > >> Sounds like a plan. I have created a task against the 6.1
> milestone:
> > >>
> > >> https://devel.rtems.org/ticket/4126
> > >>
> > >>> I think it is hard to actively encourage our users to use
> > libbsd if we have an
> > >>> enable or waf equivalent at hand in rtems.git.
> > >>>
> > >>> I'd love it to go in its own separate repo. Is that at all
> > possible? What's
> > >>> required?
> > >> I suggest we move it to a top level repo with the network demo
> > code and then see
> > >> what happens. In theory it should be easy to build with rtems_waf.
> > >>
> > >> The remaining fragments of code can be removed from the BSP files
> > and maybe
> > >> moved to a header file in the new repo once we have made the
> split.
> > >>
> > >> The change will break existing users but I think we need to make
> > the change.
> > >> Users who still depend on this stack need to either post here and
> > make us aware,
> > >> post fixes or directly contact you, me or others for support
> options.
> > > Maintaining or removing the old network stack is both fine for me.
> > Moving the stuff out of the RTEMS repository is a bit of work.
> > > ___
> > > devel mailing list
> > > devel@rtems.org 
> > > http://lists.rtems.org/mailman/listinfo/devel
> >
> > The footprint is larger.  I forget exactly which board I was
> > evaluating but I couldn't always use the "libbsd" stack and made it
> > conditional.
> >
> >
> > The footprint is an issue but even on boards with enough memory, there
> > will be effort required to move to the new stack.
>

Agreed.

For one, There are drivers for the legacy stack not in libbsd. The sparc
NIC drivers are in this bucket for sure. And then there is just the general
issue of gluing the layers together, etc.


> >
> >
> >
> > I didn't spend much time trying to reduce the footprint.  Maybe if
> > I'd removed some of the shell commands it would have been smaller.
> >
> >
> > It would be interesting to see what the smallest application that has
> > libbsd TCP/IP IPV4 in it could be. The old stack has a netdemo with a
> > couple of echo tasks which could come in around 250-300K code space. And
> > usually you didn't need a huge amount of buffers but the interfaces were
> > usually much slower. Even 100BaseT can require a lot of memory for
> > buffering.
>
> Note that you can reduce the footprint a bit by using the minimal
> buildset. It throws out stuff like IPv6 (who needs such modern stuff
> anyway?). But you will currently not reach the old stack. Maybe we
> should work towards throwing out more stuff out of the minimal buildset
> to make it smaller ;-)
>

This is the one barrier that we can work on without much effort and it
is generally beneficial long term. And lower is good from multiple
viewpoints.

>
At this point, I don't know that we have a good feel for a recommendation
for minimum code and data space.

>
> >
> > I recall adding a way to tune the default buffering per socket because I
> > helped with an app where it required about 1MB per socket by default.
> >
> > The old stack is just that old -- it was optimized for older hardware --
> > but it hasn't kept up with any potential fixes and as Chris pointed out
> > there is now a known issue against Windows. I'd like to encourage people
> > to move but unfortunately know some may want to do the risk calculation
> > and keep using it.
> >
> > Chris and I chatted about this. We thought removing it from rtems proper
> > and just creating another repo with just the files removed in their
> > current layout is the minimum legwork to make it possible to revive it
> > if someone asks. But we wouldn't touch it more unless someone REALLY
> > wants it revived.
> >
> >
> > An alternative is "lwIP".  I don't have experience with that.  Maybe
> > "lwIP" and "libbsd" should be the recommended solutions.
> >
> >
> > lwIP may be a good option for many but it still leaves you with a driver
> 

Re: [PATCH v2] rtems: Generate

[Sebastian Huber]

On 07/10/2020 17:26, Gedare Bloom wrote:


Thinking about the discussion about ordering directives in the docs,
the generated header reorders directives also. Is it also doing
generation by alphabetical order?

Should we consider using the same order as defined for the API
documentation? I guess this would make the Doxygen consistently
ordered wrt the docs.
This would make things a lot more complicated. For the Doxygen we have 
to take also the C language into account. For example before you use a 
type, it must be declared. This is done through automatic dependency 
tracking and a topological sorting. Adding a manual order into this 
stuff would be difficult.

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

Re: [PATCH v2] rtems: Generate

[Gedare Bloom]

On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
 wrote:
>
> On 07/10/2020 17:26, Gedare Bloom wrote:
>
> > Thinking about the discussion about ordering directives in the docs,
> > the generated header reorders directives also. Is it also doing
> > generation by alphabetical order?
> >
> > Should we consider using the same order as defined for the API
> > documentation? I guess this would make the Doxygen consistently
> > ordered wrt the docs.
> This would make things a lot more complicated. For the Doxygen we have
> to take also the C language into account. For example before you use a
> type, it must be declared. This is done through automatic dependency
> tracking and a topological sorting. Adding a manual order into this
> stuff would be difficult.

Yeah, maybe. The value of ordering in the headers and doxygen is
probably less than in a manual. We can revisit later if we like. It
shouldn't be too hard in an API header (as opposed to an
implementation header with inlines) to group first the typedefs and
then the function declarations. But I have no real concern about the
ordering here, it was just a thought.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Documentation image source

[Chris Johns]

Hi,

In an update of my rtems-docs.git repo I noticed some new image source formats:

$ find . -name \*.dot
./images/eng/bld-bsp.dot
./images/eng/bld-deps2.dot
./images/eng/bld-bsp2.dot
./images/eng/bld-deps.dot

Do we have a policy on what image source types can be used? Any additional image
source needs to support FreeBSD and Linux.

Images can be difficult to get right so I understand there is a need for
flexibility and tolerance but I think we need to consider how we manage the
process and quality so we maintained high quality documentation. For example on
my desktop I cannot read the HTML `bld-deps.png` and clicking on it loads a
small image which is clearer but small. The page is ...

https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items

The PDF view looks OK.

I can see we have as image source the following extensions:

 .puml
 .ditaa
 .svg
 .dot
 .odg

Some formats are old and imported so we live with those but maybe we need
tickets to have them move to something that is simpler to maintain.

I see generated .png and .pdf for some images which I am questioning we need.
The user document images I have contributed are only .png files so I am not sure
why a PDF is needed for some.

How are the .dot image sources converted to the required output format(s)? I
cannot see any information on what to do, what packages I need to install and
the options I need. For the puml and ditaa source I contributed I added waf
support, tested on Linux and FreeBSD and update the top level doco.

Sorry to be a pain about this but I think it is better we sort this out before
we all move on and forget how they are created.

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

Re: Documentation image source

[Joel Sherrill]

On Wed, Oct 7, 2020, 8:01 PM Chris Johns  wrote:

> Hi,
>
> In an update of my rtems-docs.git repo I noticed some new image source
> formats:
>
> $ find . -name \*.dot
> ./images/eng/bld-bsp.dot
> ./images/eng/bld-deps2.dot
> ./images/eng/bld-bsp2.dot
> ./images/eng/bld-deps.dot
>
> Do we have a policy on what image source types can be used? Any additional
> image
> source needs to support FreeBSD and Linux.
>
> Images can be difficult to get right so I understand there is a need for
> flexibility and tolerance but I think we need to consider how we manage the
> process and quality so we maintained high quality documentation. For
> example on
> my desktop I cannot read the HTML `bld-deps.png` and clicking on it loads a
> small image which is clearer but small. The page is ...
>
>
> https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items
>
> The PDF view looks OK.
>
> I can see we have as image source the following extensions:
>
>  .puml
>  .ditaa
>  .svg
>  .dot
>  .odg
>
> Some formats are old and imported so we live with those but maybe we need
> tickets to have them move to something that is simpler to maintain.
>
> I see generated .png and .pdf for some images which I am questioning we
> need.
> The user document images I have contributed are only .png files so I am
> not sure
> why a PDF is needed for some.
>
> How are the .dot image sources converted to the required output format(s)?
> I
> cannot see any information on what to do, what packages I need to install
> and
> the options I need. For the puml and ditaa source I contributed I added waf
> support, tested on Linux and FreeBSD and update the top level doco.
>

Graphviz.

If you can build Doxygen with graphics, you should have dot. We want dot
for sure.


> Sorry to be a pain about this but I think it is better we sort this out
> before
> we all move on and forget how they are created.
>
> Chris
> ___
> 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: Documentation image source

[Chris Johns]

On 8/10/20 12:04 pm, Joel Sherrill wrote:
> On Wed, Oct 7, 2020, 8:01 PM Chris Johns  > wrote:
> 
> Hi,
> 
> In an update of my rtems-docs.git repo I noticed some new image source 
> formats:
> 
> $ find . -name \*.dot
> ./images/eng/bld-bsp.dot
> ./images/eng/bld-deps2.dot
> ./images/eng/bld-bsp2.dot
> ./images/eng/bld-deps.dot
> 
> Do we have a policy on what image source types can be used? Any 
> additional image
> source needs to support FreeBSD and Linux.
> 
> Images can be difficult to get right so I understand there is a need for
> flexibility and tolerance but I think we need to consider how we manage 
> the
> process and quality so we maintained high quality documentation. For 
> example on
> my desktop I cannot read the HTML `bld-deps.png` and clicking on it loads 
> a
> small image which is clearer but small. The page is ...
> 
> 
> https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items
> 
> The PDF view looks OK.
> 
> I can see we have as image source the following extensions:
> 
>  .puml
>  .ditaa
>  .svg
>  .dot
>  .odg
> 
> Some formats are old and imported so we live with those but maybe we need
> tickets to have them move to something that is simpler to maintain.
> 
> I see generated .png and .pdf for some images which I am questioning we 
> need.
> The user document images I have contributed are only .png files so I am 
> not sure
> why a PDF is needed for some.
> 
> How are the .dot image sources converted to the required output 
> format(s)? I
> cannot see any information on what to do, what packages I need to install 
> and
> the options I need. For the puml and ditaa source I contributed I added 
> waf
> support, tested on Linux and FreeBSD and update the top level doco.
> 
> 
> Graphviz. 

Thanks but I was hoping for something a little more specific, like a `pkg
install ...` command and a command line to run. I think it is important when
wanting to maintaining quality. :)

> 
> If you can build Doxygen with graphics, you should have dot. We want dot for 
> sure.
> 

Sure, happy to be dot source integrated and managed.

Chris

> 
> Sorry to be a pain about this but I think it is better we sort this out 
> before
> we all move on and forget how they are created.
> 
> Chris
> ___
> 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: [PATCH 1/2] rtems: Add "Generated from ..." comments

[Chris Johns]

On 7/10/20 9:14 pm, Sebastian Huber wrote:
> Improve file header comment.

This is great.

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

Re: [PATCH 1/2] rtems: Add "Generated from ..." comments

[Joel Sherrill]

On Wed, Oct 7, 2020, 10:14 PM Chris Johns  wrote:

> On 7/10/20 9:14 pm, Sebastian Huber wrote:
> > Improve file header comment.
>
> This is great.
>

Agreed. I assume the spec: is defined somewhere.

>
> Thanks
> Chris
> ___
> 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: Documentation image source

[Joel Sherrill]

On Wed, Oct 7, 2020, 8:12 PM Chris Johns  wrote:

> On 8/10/20 12:04 pm, Joel Sherrill wrote:
> > On Wed, Oct 7, 2020, 8:01 PM Chris Johns  > > wrote:
> >
> > Hi,
> >
> > In an update of my rtems-docs.git repo I noticed some new image
> source formats:
> >
> > $ find . -name \*.dot
> > ./images/eng/bld-bsp.dot
> > ./images/eng/bld-deps2.dot
> > ./images/eng/bld-bsp2.dot
> > ./images/eng/bld-deps.dot
> >
> > Do we have a policy on what image source types can be used? Any
> additional image
> > source needs to support FreeBSD and Linux.
> >
> > Images can be difficult to get right so I understand there is a need
> for
> > flexibility and tolerance but I think we need to consider how we
> manage the
> > process and quality so we maintained high quality documentation. For
> example on
> > my desktop I cannot read the HTML `bld-deps.png` and clicking on it
> loads a
> > small image which is clearer but small. The page is ...
> >
> >
> https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items
> >
> > The PDF view looks OK.
> >
> > I can see we have as image source the following extensions:
> >
> >  .puml
> >  .ditaa
> >  .svg
> >  .dot
> >  .odg
> >
> > Some formats are old and imported so we live with those but maybe we
> need
> > tickets to have them move to something that is simpler to maintain.
> >
> > I see generated .png and .pdf for some images which I am questioning
> we need.
> > The user document images I have contributed are only .png files so I
> am not sure
> > why a PDF is needed for some.
> >
> > How are the .dot image sources converted to the required output
> format(s)? I
> > cannot see any information on what to do, what packages I need to
> install and
> > the options I need. For the puml and ditaa source I contributed I
> added waf
> > support, tested on Linux and FreeBSD and update the top level doco.
> >
> >
> > Graphviz.
>
> Thanks but I was hoping for something a little more specific, like a `pkg
> install ...` command and a command line to run. I think it is important
> when
> wanting to maintaining quality. :)
>

That is the name of the package. May vary with upper or lower case. CentOS
RPM is graphviz.

Are there any figures we do not appear to have source for? Or they aren't
in an open format? I thought we had killed all those in our last Google
Code In.



> >
> > If you can build Doxygen with graphics, you should have dot. We want dot
> for sure.
> >
>
> Sure, happy to be dot source integrated and managed.
>

I surprised one of my sons by using dot to show them the dependency graph
for them to graduate on time. Coloured nodes based on semester offered and
could visually identify longest sequence of courses and which had no
prerequisites left for him.

PlantUML can draw more types of figures and they often look better but it
can embed dot.

--joel

>
> Chris
>
> >
> > Sorry to be a pain about this but I think it is better we sort this
> out before
> > we all move on and forget how they are created.
> >
> > Chris
> > ___
> > 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: Documentation image source

[Chris Johns]

On 8/10/20 2:23 pm, Joel Sherrill wrote:
> On Wed, Oct 7, 2020, 8:12 PM Chris Johns  > wrote:
> On 8/10/20 12:04 pm, Joel Sherrill wrote:
> > On Wed, Oct 7, 2020, 8:01 PM Chris Johns  
> > >> wrote:
> >
> >     Hi,
> >
> >     In an update of my rtems-docs.git repo I noticed some new image 
> source
> formats:
> >
> >     $ find . -name \*.dot
> >     ./images/eng/bld-bsp.dot
> >     ./images/eng/bld-deps2.dot
> >     ./images/eng/bld-bsp2.dot
> >     ./images/eng/bld-deps.dot
> >
> >     Do we have a policy on what image source types can be used? Any
> additional image
> >     source needs to support FreeBSD and Linux.
> >
> >     Images can be difficult to get right so I understand there is a 
> need for
> >     flexibility and tolerance but I think we need to consider how we
> manage the
> >     process and quality so we maintained high quality documentation. For
> example on
> >     my desktop I cannot read the HTML `bld-deps.png` and clicking on it
> loads a
> >     small image which is clearer but small. The page is ...
> >
> >   
>  
> https://docs.rtems.org/branches/master/eng/build-system.html#build-specification-items
> >
> >     The PDF view looks OK.
> >
> >     I can see we have as image source the following extensions:
> >
> >      .puml
> >      .ditaa
> >      .svg
> >      .dot
> >      .odg
> >
> >     Some formats are old and imported so we live with those but maybe 
> we need
> >     tickets to have them move to something that is simpler to maintain.
> >
> >     I see generated .png and .pdf for some images which I am questioning
> we need.
> >     The user document images I have contributed are only .png files so I
> am not sure
> >     why a PDF is needed for some.
> >
> >     How are the .dot image sources converted to the required output
> format(s)? I
> >     cannot see any information on what to do, what packages I need to
> install and
> >     the options I need. For the puml and ditaa source I contributed I
> added waf
> >     support, tested on Linux and FreeBSD and update the top level doco.
> >
> >
> > Graphviz.
> 
> Thanks but I was hoping for something a little more specific, like a `pkg
> install ...` command and a command line to run. I think it is important 
> when
> wanting to maintaining quality. :)
> 
> That is the name of the package. May vary with upper or lower case. CentOS RPM
> is graphviz.

I am sure it is something like that on FreeBSD. I have not looked.

> Are there any figures we do not appear to have source for? Or they aren't in 
> an
> open format? I thought we had killed all those in our last Google Code In.

Good question, I think there are some I did a long time ago that might need to
be redone. The svg ones. I have not checked.

> >
> > If you can build Doxygen with graphics, you should have dot. We want dot
> for sure.
> >
> 
> Sure, happy to be dot source integrated and managed.
> 
> I surprised one of my sons by using dot to show them the dependency graph for
> them to graduate on time. Coloured nodes based on semester offered and could
> visually identify longest sequence of courses and which had no prerequisites
> left for him.

That is such a nerd Dad solution! Well done, I love it :)

> PlantUML can draw more types of figures and they often look better but it can
> embed dot.

OK, I have not used dot so I do not know. The concern is not so much the tool
but the options used to make something work and be just right. We need to
capture what is used.

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

Re: [PATCH 1/2] rtems: Add "Generated from ..." comments

[Chris Johns]

On 8/10/20 2:18 pm, Joel Sherrill wrote:
> On Wed, Oct 7, 2020, 10:14 PM Chris Johns  > wrote:
> On 7/10/20 9:14 pm, Sebastian Huber wrote:
> > Improve file header comment.
> 
> This is great.
> 
> Agreed. I assume the spec: is defined somewhere.

The patch has ...

+/* Generated from spec:/rtems/if/group */

and the file is ...

https://git.rtems.org/rtems-central/tree/spec/rtems/if/group.yml

These addition are a really good productivity improvement. It takes seconds to
find the file and there is no guess work involved.

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

Re: Documentation image source

[Sebastian Huber]

On 08/10/2020 03:01, Chris Johns wrote:


I see generated .png and .pdf for some images which I am questioning we need.
The user document images I have contributed are only .png files so I am not sure
why a PDF is needed for some.
Images in a vector format is very important for a high quality PDF. 
Using PNG for the PDFs is not really good.

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

[PATCH] grlib: Add and use irqmp_has_timestamp()

[Sebastian Huber]

Replace leon3_irqmp_has_timestamp() with irqmp_has_timestamp() and move
it to grlib.h.

Close #4128.
---
 bsps/riscv/griscv/clock/clockdrv.c | 2 +-
 bsps/shared/grlib/btimer/tlib_ckinit.c | 2 +-
 bsps/sparc/leon3/clock/ckinit.c| 4 ++--
 bsps/sparc/leon3/include/leon.h| 7 ---
 bsps/sparc/leon3/start/cpucounter.c| 2 +-
 5 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/bsps/riscv/griscv/clock/clockdrv.c 
b/bsps/riscv/griscv/clock/clockdrv.c
index c94c167fdf..4cf15fe4f8 100644
--- a/bsps/riscv/griscv/clock/clockdrv.c
+++ b/bsps/riscv/griscv/clock/clockdrv.c
@@ -171,7 +171,7 @@ static void grlib_clock_initialize(void)
   volatile struct irqmp_timestamp_regs *irqmp_ts =
 &GRLIB_IrqCtrl_Regs->timestamp[0];
 
-if (!grlib_irqmp_has_timestamp(irqmp_ts)) {
+if (!irqmp_has_timestamp(irqmp_ts)) {
   bsp_fatal(GRLIB_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
 }
 #endif
diff --git a/bsps/shared/grlib/btimer/tlib_ckinit.c 
b/bsps/shared/grlib/btimer/tlib_ckinit.c
index 4f679984d8..5a34d97c00 100644
--- a/bsps/shared/grlib/btimer/tlib_ckinit.c
+++ b/bsps/shared/grlib/btimer/tlib_ckinit.c
@@ -126,7 +126,7 @@ static rtems_device_driver tlib_clock_find_timer(void)
 volatile struct irqmp_timestamp_regs *irqmp_ts;
 
 irqmp_ts = &LEON3_IrqCtrl_Regs->timestamp[0];
-if (leon3_irqmp_has_timestamp(irqmp_ts)) {
+if (irqmp_has_timestamp(irqmp_ts)) {
   priv.ops = &ops_irqamp;
   return RTEMS_SUCCESSFUL;
 }
diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
index f485123f6b..bf0c506ec0 100644
--- a/bsps/sparc/leon3/clock/ckinit.c
+++ b/bsps/sparc/leon3/clock/ckinit.c
@@ -176,13 +176,13 @@ static void leon3_clock_initialize(void)
 tc->tc_frequency = leon3_up_counter_frequency();
 
 #ifdef RTEMS_PROFILING
-if (!leon3_irqmp_has_timestamp(irqmp_ts)) {
+if (!irqmp_has_timestamp(irqmp_ts)) {
   bsp_fatal(LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
 }
 #endif
 
 leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
-  } else if (leon3_irqmp_has_timestamp(irqmp_ts)) {
+  } else if (irqmp_has_timestamp(irqmp_ts)) {
 /* Use the interrupt controller timestamp counter if available */
 tc->tc_get_timecount = _SPARC_Get_timecount_up;
 tc->tc_frequency = ambapp_freq_get(&ambapp_plb, LEON3_Timer_Adev);
diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
index afe0d91ca4..d25825c8e8 100644
--- a/bsps/sparc/leon3/include/leon.h
+++ b/bsps/sparc/leon3/include/leon.h
@@ -454,13 +454,6 @@ static inline uint32_t 
leon3_get_data_cache_config_register(void)
   return leon3_get_system_register(0xc);
 }
 
-static inline bool leon3_irqmp_has_timestamp(
-  volatile struct irqmp_timestamp_regs *irqmp_ts
-)
-{
-  return (irqmp_ts->control >> 27) > 0;
-}
-
 static inline uint32_t leon3_up_counter_low(void)
 {
   uint32_t asr23;
diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index 007bb6d8ec..1d96e3b221 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -43,7 +43,7 @@ static void leon3_counter_initialize(void)
 counter->read = _SPARC_Counter_read_asr23;
 
 leon3_counter_frequency = leon3_up_counter_frequency();
-  } else if (leon3_irqmp_has_timestamp(irqmp_ts)) {
+  } else if (irqmp_has_timestamp(irqmp_ts)) {
 /* Use the interrupt controller timestamp counter if available */
 counter->read_isr_disabled = _SPARC_Counter_read_up;
 counter->read = _SPARC_Counter_read_up;
-- 
2.26.2

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

Re: Documentation image source

[Chris Johns]

On 8/10/20 4:31 pm, Sebastian Huber wrote:
> On 08/10/2020 03:01, Chris Johns wrote:
> 
>> I see generated .png and .pdf for some images which I am questioning we need.
>> The user document images I have contributed are only .png files so I am not 
>> sure
>> why a PDF is needed for some.
> Images in a vector format is very important for a high quality PDF. Using PNG
> for the PDFs is not really good.

Yes is does help but I am not convinced by the "very important" bit. I looked at
the user manual executable pictures in the PDF at 400% on a quality monitor and
they hold up nicely. All you get to see is the anti-aliasing effects which is
understandable.

HTML and PDF need to be at the same quality level and I have shown this can be
achieved even with .png files. PDF is not something we should treat as special.
At the moment I cannot read the dot HTML images.

The PDF quality depends on the contents of the PDF fragment. It may not always
be vectors so I am not sure we can assume this. I have seen PDF get abused with
horrible results. It looks like .dot is vector which is fine.

Manual generation is something I would like to avoid and especially if more than
one output file type is being generated. The poor HTML quality of the dot
generated .png files highlights this. Can they please be improved?

Chris


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

Re: [PATCH v2] rtems: Generate

[Sebastian Huber]

On 07/10/2020 21:12, Gedare Bloom wrote:


On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
 wrote:

On 07/10/2020 17:26, Gedare Bloom wrote:


Thinking about the discussion about ordering directives in the docs,
the generated header reorders directives also. Is it also doing
generation by alphabetical order?

Should we consider using the same order as defined for the API
documentation? I guess this would make the Doxygen consistently
ordered wrt the docs.

This would make things a lot more complicated. For the Doxygen we have
to take also the C language into account. For example before you use a
type, it must be declared. This is done through automatic dependency
tracking and a topological sorting. Adding a manual order into this
stuff would be difficult.

Yeah, maybe. The value of ordering in the headers and doxygen is
probably less than in a manual. We can revisit later if we like. It
shouldn't be too hard in an API header (as opposed to an
implementation header with inlines) to group first the typedefs and
then the function declarations. But I have no real concern about the
ordering here, it was just a thought.


Good, I added a ticket for this:

https://devel.rtems.org/ticket/4134#ticket

It is not on my high priority list.

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

Re: Documentation image source

[Sebastian Huber]

On 08/10/2020 08:18, Chris Johns wrote:


On 8/10/20 4:31 pm, Sebastian Huber wrote:

On 08/10/2020 03:01, Chris Johns wrote:


I see generated .png and .pdf for some images which I am questioning we need.
The user document images I have contributed are only .png files so I am not sure
why a PDF is needed for some.

Images in a vector format is very important for a high quality PDF. Using PNG
for the PDFs is not really good.

Yes is does help but I am not convinced by the "very important" bit. I looked at
the user manual executable pictures in the PDF at 400% on a quality monitor and
they hold up nicely. All you get to see is the anti-aliasing effects which is
understandable.

HTML and PDF need to be at the same quality level and I have shown this can be
achieved even with .png files. PDF is not something we should treat as special.
At the moment I cannot read the dot HTML images.

The PDF quality depends on the contents of the PDF fragment. It may not always
be vectors so I am not sure we can assume this. I have seen PDF get abused with
horrible results. It looks like .dot is vector which is fine.

Manual generation is something I would like to avoid and especially if more than
one output file type is being generated. The poor HTML quality of the dot
generated .png files highlights this. Can they please be improved?
It would be nice to use a vector format for HTML also. Maybe we should 
use SVG instead of PNG.

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

[PATCH v2] rtems: Generate

[Sebastian Huber]

The manager documentation is a consolidation of the comments in Doxygen
markup and the documentation sources in Sphinx markup.  The
documentation was transfered to interface specification items.  This
header file was generated from the items by a script.

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

Update #3899.
Update #3993.
---
v2:

* Fix some typos.

Doxygen output can be reviewed here:

https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicIO.html

https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicEvent.html

https://ftp.rtems.org/pub/rtems/people/sebh/doc/html/group__RTEMSAPIClassicPart.html

 cpukit/include/rtems/io.h | 499 --
 1 file changed, 377 insertions(+), 122 deletions(-)

diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
index 67364df280..5fc984ed44 100644
--- a/cpukit/include/rtems/io.h
+++ b/cpukit/include/rtems/io.h
@@ -1,228 +1,483 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
- * @brief Classic Input/Output Manager API
- * 
- * This file emulates the old Classic RTEMS IO manager directives
- * which register names using the in-memory filesystem.
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This header file defines the IO Manager API.
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 1988, 2008 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 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) 1989-2008.
- *  On-Line Applications Research Corporation (OAR).
+ * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ *
+ * https://docs.rtems.org/branches/master/user/support/bugs.html
+ *
+ * For information on updating and regenerating please refer to:
  *
- *  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/branches/master/eng/req/howto.html
  */
 
+/* Generated from spec:/rtems/io/if/header */
+
 #ifndef _RTEMS_IO_H
 #define _RTEMS_IO_H
 
+#include 
 #include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/io/if/group */
+
 /**
- * @defgroup ClassicIO Input/Output
+ * @defgroup RTEMSAPIClassicIO I/O Manager
  *
  * @ingroup RTEMSAPIClassic
  *
+ * @brief The Input/Output (I/O) Manager provides a well-defined mechanism for
+ *   accessing device drivers and a structured methodology for organizing
+ *   device drivers.
  */
-/**@{**/
 
-typedef uint32_t rtems_device_major_number;
+/* Generated from spec:/rtems/io/if/device-minor-number */
 
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This integer type represents the minor number of devices.
+ *
+ * The minor number of devices is managed by the device driver.
+ */
 typedef uint32_t rtems_device_minor_number;
 
+/* Generated from spec:/rtems/io/if/device-major-number */
+
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This integer type represents the major number of devices.
+ *
+ * The major number of a device is determined by rtems_io_register_driver() and
+ * the application configuration (see #CONFIGURE_MAXIMUM_DRIVERS) .
+ */
+typedef uint32_t rtems_device_major_number;
+
+/* Generated from spec:/rtems/io/if/device-driver */
+
+/**
+ * @ingroup RTEMSAPIClassicIO
+ *
+ * @brief This type shall be used in device driver entry declarations and
+ *   definitions.
+

Re: Documentation image source

[Chris Johns]

On 8/10/20 5:30 pm, Sebastian Huber wrote:
> On 08/10/2020 08:18, Chris Johns wrote:
>> On 8/10/20 4:31 pm, Sebastian Huber wrote:
>>> On 08/10/2020 03:01, Chris Johns wrote:
>>>
 I see generated .png and .pdf for some images which I am questioning we 
 need.
 The user document images I have contributed are only .png files so I am not
 sure
 why a PDF is needed for some.
>>> Images in a vector format is very important for a high quality PDF. Using 
>>> PNG
>>> for the PDFs is not really good.
>> Yes is does help but I am not convinced by the "very important" bit. I 
>> looked at
>> the user manual executable pictures in the PDF at 400% on a quality monitor 
>> and
>> they hold up nicely. All you get to see is the anti-aliasing effects which is
>> understandable.
>>
>> HTML and PDF need to be at the same quality level and I have shown this can 
>> be
>> achieved even with .png files. PDF is not something we should treat as 
>> special.
>> At the moment I cannot read the dot HTML images.
>>
>> The PDF quality depends on the contents of the PDF fragment. It may not 
>> always
>> be vectors so I am not sure we can assume this. I have seen PDF get abused 
>> with
>> horrible results. It looks like .dot is vector which is fine.
>>
>> Manual generation is something I would like to avoid and especially if more 
>> than
>> one output file type is being generated. The poor HTML quality of the dot
>> generated .png files highlights this. Can they please be improved?
> It would be nice to use a vector format for HTML also. Maybe we should use SVG
> instead of PNG.

That would be a nice solution but I have no idea how to do that. It would have
to work on all browsers on all devices. That is an area where the less I know
the happier I am. Is simpler better in this case, that is a suitably size image?

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