Re: RTEMS Documentation BSD licensing

[Sebastian Huber]

Hello Martin,

On 06/03/2020 19:36, Martin Erik Werner wrote:

Based on the dual-licensing work done as part of
https://devel.rtems.org/ticket/3899 I was wondering what the licensing
state would be for the documentation going forward?

Previously, as far as I understand it, contributions were implicitly
licensed under BY-SA (CC-BY-SA-4.0 international) by the author and
RTEMS uses and redistributes the content with this license?


yes.



With this dual-licensing I understand that contributions will now be
implicitly licensed under both BSD (BSD-2-Clause) and BY-SA by the
author for contributions to some (or all?) parts.

Is there any documentation that will indicate this more specifically?
"If you contribute to this item, your agre to provide your
contributions under this(these) license(s)".


What matters from my point of view is the license header of the 
individual files. For the documentation we don't have guidelines 
included in the RTEMS Software Engineering manual. Maybe we should start 
with this and mention the licencing background.


For the RTEMS Qualification Project I would like to generate content 
from the specification. For example, we have documentation of API 
functions in Doxygen and the Classic API Guide:


https://docs.rtems.org/doxygen/branches/master/group__ClassicTasks.html#gabffda1c2301962f0ae5af042ac0bba62

https://docs.rtems.org/branches/master/c-user/task_manager.html#task-create-create-a-task

One goal of the pre-qualification activity is to introduce a master data 
set (specification) and use tools to generate content in the right 
format from it. The specification consists of individual files with 
attributes (key-value pairs), for example:


https://git.rtems.org/sebh/rtems-qual.git/tree/spec/glos/term/RTEMS-GLOS-TERM-TASK.yml

The files have a license and copyrights attribute, e.g.

SPDX-License-Identifier: CC-BY-SA-4.0
copyrights:
- Copyright (C) 2017 embedded brains GmbH (http://www.embedded-brains.de)
- Copyright (C) 1988, 1998 On-Line Applications Research Corporation (OAR)

For a generated document this information is aggregated and checked that 
the target license is compatible to all the individual contributions, e.g.


https://git.rtems.org/rtems-docs/tree/c-user/glossary.rst

This file was generated by:

https://git.rtems.org/sebh/rtems-qual.git/tree/rtems_spec_to_x.py

If we want to generate also Doxygen markup for header files, then the 
specification items need a dual CC-BY-SA-4.0 or BSD-2-Clause license so 
that the RTEMS sources are still BSD-2-Clause. My task is now to collect 
existing content form the RTEMS documentation and sources to build up 
the specification items. For this I have to be very careful with the 
copyright and license information.




Will the documentation with inbound BSD/BY-SA contributions still be
outbound licensed under BY-SA in the "web" documentation? Or will this
documenation shift to being outbound BSD/BY-SA as well?


The published documentation will be CC-BY-SA-4.0. Only some 
documentation sources (or specification items) will have a dual license.




BSD is inbound compatible with BY-SA, right? If so I would guess that
providing contributions under BSD would be the same as providing them
under BSD and BY-SA (since one can simply take BSD and make it BY-SA)?


I am not sure.



Assuming that BSD is inbound compatible with BY-SA, would it then make
sense to use only BSD as both inbound and outbound for the doxygen-
shared part of the "web" documentation?


I think using

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause

for content intended for the RTEMS sources and documentation makes it 
clear. This reasoning about license transformations is not really my 
area of expertise.




If it remains outbound BY-SA-only there would be an assymetry, and for
example have the mild hitch that only the RTEMS project itself is
allowed to copy documentation to BSD-doxygen.


The RTEMS Project is not a copyright holder. The license of a document 
is determined by the licenses of the source files.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 07/20] c-user: Move "Task Stack Allocator Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst  | 111 +-
 c-user/config/stack-alloc-config.rst | 113 +++
 2 files changed, 114 insertions(+), 110 deletions(-)
 create mode 100644 c-user/config/stack-alloc-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index 4333495..c99a3cf 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -17,116 +17,7 @@ Configuring a System
 classic-init-task-config
 posix-api-config
 posix-init-thread-config
-
-Task Stack Allocator Configuration
-==
-
-RTEMS allows the application or BSP to define its own allocation and
-deallocation methods for task stacks. This can be used to place task stacks in
-special areas of memory or to utilize a Memory Management Unit so that stack
-overflows are detected in hardware.
-
-.. index:: CONFIGURE_TASK_STACK_ALLOCATOR
-.. index:: task stack allocator
-
-.. _CONFIGURE_TASK_STACK_ALLOCATOR:
-
-CONFIGURE_TASK_STACK_ALLOCATOR
---
-
-CONSTANT:
-``CONFIGURE_TASK_STACK_ALLOCATOR``
-
-DATA TYPE:
-Function pointer.
-
-RANGE:
-Undefined or valid function pointer.
-
-DEFAULT VALUE:
-The default value is ``_Workspace_Allocate``, which indicates that task
-stacks will be allocated from the RTEMS Workspace.
-
-DESCRIPTION:
-``CONFIGURE_TASK_STACK_ALLOCATOR`` may point to a user provided routine to
-allocate task stacks.
-
-NOTES:
-A correctly configured system must configure the following to be 
consistent:
-
-- ``CONFIGURE_TASK_STACK_ALLOCATOR_INIT``
-
-- ``CONFIGURE_TASK_STACK_ALLOCATOR``
-
-- ``CONFIGURE_TASK_STACK_DEALLOCATOR``
-
-.. index:: CONFIGURE_TASK_STACK_ALLOCATOR_INIT
-
-.. _CONFIGURE_TASK_STACK_ALLOCATOR_INIT:
-
-CONFIGURE_TASK_STACK_ALLOCATOR_INIT

-
-CONSTANT:
-``CONFIGURE_TASK_STACK_ALLOCATOR_INIT``
-
-DATA TYPE:
-Function pointer.
-
-RANGE:
-Undefined, NULL or valid function pointer.
-
-DEFAULT VALUE:
-The default value is NULL, which indicates that task stacks will be
-allocated from the RTEMS Workspace.
-
-DESCRIPTION:
-``CONFIGURE_TASK_STACK_ALLOCATOR_INIT`` configures the initialization
-method for an application or BSP specific task stack allocation
-implementation.
-
-NOTES:
-A correctly configured system must configure the following to be 
consistent:
-
-- ``CONFIGURE_TASK_STACK_ALLOCATOR_INIT``
-
-- ``CONFIGURE_TASK_STACK_ALLOCATOR``
-
-- ``CONFIGURE_TASK_STACK_DEALLOCATOR``
-
-.. index:: CONFIGURE_TASK_STACK_DEALLOCATOR
-.. index:: task stack deallocator
-
-.. _CONFIGURE_TASK_STACK_DEALLOCATOR:
-
-CONFIGURE_TASK_STACK_DEALLOCATOR
-
-
-CONSTANT:
-``CONFIGURE_TASK_STACK_DEALLOCATOR``
-
-DATA TYPE:
-Function pointer.
-
-RANGE:
-Undefined or valid function pointer.
-
-DEFAULT VALUE:
-The default value is ``_Workspace_Free``, which indicates that task stacks
-will be allocated from the RTEMS Workspace.
-
-DESCRIPTION:
-``CONFIGURE_TASK_STACK_DEALLOCATOR`` may point to a user provided routine
-to free task stacks.
-
-NOTES:
-A correctly configured system must configure the following to be 
consistent:
-
-- ``CONFIGURE_TASK_STACK_ALLOCATOR_INIT``
-
-- ``CONFIGURE_TASK_STACK_ALLOCATOR``
-
-- ``CONFIGURE_TASK_STACK_DEALLOCATOR``
+stack-alloc-config
 
 Message Queue Buffer Configuration
 ==
diff --git a/c-user/config/stack-alloc-config.rst 
b/c-user/config/stack-alloc-config.rst
new file mode 100644
index 000..a96bbdc
--- /dev/null
+++ b/c-user/config/stack-alloc-config.rst
@@ -0,0 +1,113 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Task Stack Allocator Configuration
+==
+
+RTEMS allows the application or BSP to define its own allocation and
+deallocation methods for task stacks. This can be used to place task stacks in
+special areas of memory or to utilize a Memory Management Unit so that stack
+overflows are detected in hardware.
+
+.. index:: CONFIGURE_TASK_STACK_ALLOCATOR
+.. index:: task stack allocator
+
+.. _CONFIGURE_TASK_STACK_ALLOCATOR:
+
+CONFIGURE_TASK_STACK_ALLOCATOR
+--
+
+CONSTANT:
+``CONFIGURE_TASK_STACK_ALLOCATOR``
+
+DATA TYPE:
+Function pointer.
+
+RANGE:
+Undefined or valid function pointer.
+
+DEFAULT VALUE:
+The default value is ``_Workspace_Allocate``, which indicates that task
+stacks will be allocated from the RTEMS Workspace.
+
+DESCRIPTION:
+``CONFIGURE_TASK_STACK_ALLOCATOR`` may point to a user provided routine to
+allocate task stacks.
+
+NOTES:
+A correctly configured system must configure the following to be 
consistent:
+
+- ``CONFIGURE_TASK_STACK_ALLOCATOR_INIT``
+
+- ``CONFIGURE_TASK_STACK_ALLOCATOR``
+
+- ``CONFIGURE_TASK_STACK_DEALLOCATOR``
+
+..

[PATCH 02/20] c-user: Move "General System Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/general-config.rst | 639 +++
 c-user/config/index.rst  | 637 +-
 2 files changed, 640 insertions(+), 636 deletions(-)
 create mode 100644 c-user/config/general-config.rst

diff --git a/c-user/config/general-config.rst b/c-user/config/general-config.rst
new file mode 100644
index 000..f6d7531
--- /dev/null
+++ b/c-user/config/general-config.rst
@@ -0,0 +1,639 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+General System Configuration
+
+
+This section defines the general system configuration options supported by
+.
+
+.. index:: CONFIGURE_DIRTY_MEMORY
+
+.. _CONFIGURE_DIRTY_MEMORY:
+
+CONFIGURE_DIRTY_MEMORY
+--
+
+CONSTANT:
+``CONFIGURE_DIRTY_MEMORY``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+By default, the memory used by the RTEMS Workspace and the C Program Heap
+is uninitialized memory.
+
+DESCRIPTION:
+This macro indicates whether RTEMS should dirty the memory used by the
+RTEMS Workspace and the C Program Heap as part of its initialization.  If
+defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
+Otherwise, they are not.
+
+NOTES:
+Dirtying memory can add significantly to system boot time.  It may assist 
in
+finding code that incorrectly assumes the contents of free memory areas is
+cleared to zero during system initialization.  In case
+:ref:`CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY` is also defined, then the
+memory is first dirtied and then zeroed.
+
+.. index:: CONFIGURE_EXTRA_TASK_STACKS
+.. index:: memory for task tasks
+
+.. _CONFIGURE_EXTRA_TASK_STACKS:
+
+CONFIGURE_EXTRA_TASK_STACKS
+---
+
+CONSTANT:
+``CONFIGURE_EXTRA_TASK_STACKS``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Undefined or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+This configuration parameter is set to the number of bytes the applications
+wishes to add to the task stack requirements calculated by
+.
+
+NOTES:
+This parameter is very important.  If the application creates tasks with
+stacks larger then the minimum, then that memory is NOT accounted for by
+.
+
+.. index:: CONFIGURE_INITIAL_EXTENSIONS
+
+.. _CONFIGURE_INITIAL_EXTENSIONS:
+
+CONFIGURE_INITIAL_EXTENSIONS
+
+
+CONSTANT:
+``CONFIGURE_INITIAL_EXTENSIONS``
+
+DATA TYPE:
+List of user extension initializers (``rtems_extensions_table``).
+
+RANGE:
+Undefined or a list of one or more user extensions.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+If ``CONFIGURE_INITIAL_EXTENSIONS`` is defined by the application, then
+this application specific set of initial extensions will be placed in the
+initial extension table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_INTERRUPT_STACK_SIZE
+.. index:: interrupt stack size
+
+.. _CONFIGURE_INTERRUPT_STACK_SIZE:
+
+CONFIGURE_INTERRUPT_STACK_SIZE
+--
+
+CONSTANT:
+``CONFIGURE_INTERRUPT_STACK_SIZE``
+
+DATA TYPE:
+Unsigned integer.
+
+RANGE:
+Positive.
+
+DEFAULT VALUE:
+The default value is ``BSP_INTERRUPT_STACK_SIZE`` in case it is defined,
+otherwise the default value is ``CPU_STACK_MINIMUM_SIZE``.
+
+DESCRIPTION:
+The ``CONFIGURE_INTERRUPT_STACK_SIZE`` configuration option defines the
+size of an interrupt stack in bytes.
+
+NOTES:
+The interrupt stack size must be aligned according to
+``CPU_INTERRUPT_STACK_ALIGNMENT``.
+
+There is one interrupt stack available for each configured processor
+(:ref:`CONFIGURE_MAXIMUM_PROCESSORS `).  The
+interrupt stack areas are statically allocated in a special linker section
+(``.rtemsstack.interrupt``).  The placement of this linker section is
+BSP-specific.
+
+Some BSPs use the interrupt stack as the initialization stack which is used
+to perform the sequential system initialization before the multithreading
+is started.
+
+The interrupt stacks are covered by the :ref:`stack checker
+`.  However, using a too small interrupt
+stack size may still result in undefined behaviour.
+
+In releases before RTEMS 5.1 the default value was
+:ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE
+` instead of ``CPU_STACK_MINIMUM_SIZE``.
+
+.. index:: CONFIGURE_MAXIMUM_FILE_DESCRIPTORS
+.. index:: maximum file descriptors
+
+.. _CONFIGURE_MAXIMUM_FILE_DESCRIPTORS:
+
+CONFIGURE_MAXIMUM_FILE_DESCRIPTORS
+--
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_FILE_DESCRIPTORS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+If ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` is d

[PATCH 03/20] c-user: Move "Classic API Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/classic-api-config.rst | 291 +++
 c-user/config/index.rst  | 289 +-
 2 files changed, 292 insertions(+), 288 deletions(-)
 create mode 100644 c-user/config/classic-api-config.rst

diff --git a/c-user/config/classic-api-config.rst 
b/c-user/config/classic-api-config.rst
new file mode 100644
index 000..6c8f6ca
--- /dev/null
+++ b/c-user/config/classic-api-config.rst
@@ -0,0 +1,291 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Classic API Configuration
+=
+
+This section defines the Classic API related system configuration parameters
+supported by .
+
+.. index:: CONFIGURE_MAXIMUM_BARRIERS
+
+.. _CONFIGURE_MAXIMUM_BARRIERS:
+
+CONFIGURE_MAXIMUM_BARRIERS
+--
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_BARRIERS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_BARRIERS`` is the maximum number of Classic API
+Barriers that can be concurrently active.
+
+NOTES:
+This object class can be configured in unlimited allocation mode.
+
+.. index:: CONFIGURE_MAXIMUM_MESSAGE_QUEUES
+
+.. _CONFIGURE_MAXIMUM_MESSAGE_QUEUES:
+
+CONFIGURE_MAXIMUM_MESSAGE_QUEUES
+
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_MESSAGE_QUEUES``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_MESSAGE_QUEUES`` is the maximum number of Classic API
+Message Queues that can be concurrently active.
+
+NOTES:
+This object class can be configured in unlimited allocation mode.  You have
+to account for the memory used to store the messages of each message queue,
+see :ref:`CONFIGURE_MESSAGE_BUFFER_MEMORY`.
+
+.. index:: CONFIGURE_MAXIMUM_PARTITIONS
+
+.. _CONFIGURE_MAXIMUM_PARTITIONS:
+
+CONFIGURE_MAXIMUM_PARTITIONS
+
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_PARTITIONS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_PARTITIONS`` is the maximum number of Classic API
+Partitions that can be concurrently active.
+
+NOTES:
+This object class can be configured in unlimited allocation mode.
+
+.. index:: CONFIGURE_MAXIMUM_PERIODS
+
+.. _CONFIGURE_MAXIMUM_PERIODS:
+
+CONFIGURE_MAXIMUM_PERIODS
+-
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_PERIODS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_PERIODS`` is the maximum number of Classic API Periods
+that can be concurrently active.
+
+NOTES:
+This object class can be configured in unlimited allocation mode.
+
+.. index:: CONFIGURE_MAXIMUM_PORTS
+
+.. _CONFIGURE_MAXIMUM_PORTS:
+
+CONFIGURE_MAXIMUM_PORTS
+---
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_PORTS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_PORTS`` is the maximum number of Classic API Ports that
+can be concurrently active.
+
+NOTES:
+This object class can be configured in unlimited allocation mode.
+
+.. index:: CONFIGURE_MAXIMUM_REGIONS
+
+.. _CONFIGURE_MAXIMUM_REGIONS:
+
+CONFIGURE_MAXIMUM_REGIONS
+-
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_REGIONS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_REGIONS`` is the maximum number of Classic API Regions
+that can be concurrently active.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_MAXIMUM_SEMAPHORES
+
+.. _CONFIGURE_MAXIMUM_SEMAPHORES:
+
+CONFIGURE_MAXIMUM_SEMAPHORES
+
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_SEMAPHORES``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_MAXIMUM_SEMAPHORES`` is the maximum number of Classic API
+Semaphores that can be concurrently active.
+
+NOTES:
+This object class can be configured in unlimited allocation mode.
+
+In SMP configurations, the size of a Semaphore Control Block depends on the
+scheduler count (see :ref:`ConfigurationSchedulerTable`).  The semaphores
+using the :ref:`MrsP` need a ceiling priority per scheduler.
+
+.. index:: CONFIGURE_MAXIMUM_TASKS
+
+.. _CONFIGURE_MAXIMUM_TASKS:
+
+CONFIGURE_MAXIMUM_TASKS
+---
+
+CONSTANT:
+``CONFIGURE_MAXIM

[PATCH 04/20] c-user: Move "Classic API Initialization Task Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/classic-init-task-config.rst | 234 +
 c-user/config/index.rst| 232 +---
 2 files changed, 235 insertions(+), 231 deletions(-)
 create mode 100644 c-user/config/classic-init-task-config.rst

diff --git a/c-user/config/classic-init-task-config.rst 
b/c-user/config/classic-init-task-config.rst
new file mode 100644
index 000..cbbec9a
--- /dev/null
+++ b/c-user/config/classic-init-task-config.rst
@@ -0,0 +1,234 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Classic API Initialization Task Configuration
+=
+
+The  configuration system can automatically generate an
+Initialization Tasks Table named ``Initialization_tasks`` with a single entry.
+The following parameters control the generation of that table.
+
+.. index:: CONFIGURE_INIT_TASK_ARGUMENTS
+
+.. _CONFIGURE_INIT_TASK_ARGUMENTS:
+
+CONFIGURE_INIT_TASK_ARGUMENTS
+-
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_ARGUMENTS``
+
+DATA TYPE:
+RTEMS Task Argument (``rtems_task_argument``).
+
+RANGE:
+Complete range of the type.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_ARGUMENTS`` is the task argument of the single
+initialization task defined by the Classic API Initialization Tasks Table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_INIT_TASK_ATTRIBUTES
+
+.. _CONFIGURE_INIT_TASK_ATTRIBUTES:
+
+CONFIGURE_INIT_TASK_ATTRIBUTES
+--
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_ATTRIBUTES``
+
+DATA TYPE:
+RTEMS Attributes (``rtems_attribute``).
+
+RANGE:
+Valid task attribute sets.
+
+DEFAULT VALUE:
+The default value is ``RTEMS_DEFAULT_ATTRIBUTES``.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_ATTRIBUTES`` is the task attributes of the single
+initialization task defined by the Classic API Initialization Tasks Table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_INIT_TASK_ENTRY_POINT
+
+.. _CONFIGURE_INIT_TASK_ENTRY_POINT:
+
+CONFIGURE_INIT_TASK_ENTRY_POINT
+---
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_ENTRY_POINT``
+
+DATA TYPE:
+Task entry function pointer (``rtems_task_entry``).
+
+RANGE:
+Valid task entry function pointer.
+
+DEFAULT VALUE:
+The default value is ``Init``.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_ENTRY_POINT`` is the entry point (a.k.a. function
+name) of the single initialization task defined by the Classic API
+Initialization Tasks Table.
+
+NOTES:
+The user must implement the function ``Init`` or the function name provided
+in this configuration parameter.
+
+.. index:: CONFIGURE_INIT_TASK_INITIAL_MODES
+
+.. _CONFIGURE_INIT_TASK_INITIAL_MODES:
+
+CONFIGURE_INIT_TASK_INITIAL_MODES
+-
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_INITIAL_MODES``
+
+DATA TYPE:
+RTEMS Mode (``rtems_mode``).
+
+RANGE:
+Valid task mode sets.
+
+DEFAULT VALUE:
+The default value is ``RTEMS_NO_PREEMPT``.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_INITIAL_MODES`` is the initial execution mode of the
+single initialization task defined by the Classic API Initialization Tasks
+Table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_INIT_TASK_NAME
+
+.. _CONFIGURE_INIT_TASK_NAME:
+
+CONFIGURE_INIT_TASK_NAME
+
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_NAME``
+
+DATA TYPE:
+RTEMS Name (``rtems_name``).
+
+RANGE:
+Any value.
+
+DEFAULT VALUE:
+The default value is ``rtems_build_name( 'U', 'I', '1', ' ' )``.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_NAME`` is the name of the single initialization task
+defined by the Classic API Initialization Tasks Table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_INIT_TASK_PRIORITY
+
+.. _CONFIGURE_INIT_TASK_PRIORITY:
+
+CONFIGURE_INIT_TASK_PRIORITY
+
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_PRIORITY``
+
+DATA TYPE:
+RTEMS Task Priority (``rtems_task_priority``).
+
+RANGE:
+One (1) to the maximum user priority value of the scheduler.
+
+DEFAULT VALUE:
+The default value is 1, which is the highest priority in the Classic API.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_PRIORITY`` is the initial priority of the single
+initialization task defined by the Classic API Initialization Tasks Table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_INIT_TASK_STACK_SIZE
+
+.. _CONFIGURE_INIT_TASK_STACK_SIZE:
+
+CONFIGURE_INIT_TASK_STACK_SIZE
+--
+
+CONSTANT:
+``CONFIGURE_INIT_TASK_STACK_SIZE``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is RTEMS_MINIMUM_STACK_SIZE.
+
+DESCRIPTION:
+``CONFIGURE_INIT_TASK_STACK_SIZE`` is the stack size of the single
+initialization task defined by the Classic API Initialization 

[PATCH 01/20] c-user: Split up configuring_a_system.rst

[Sebastian Huber]

Introduce an index file for this chapter.  This helps to generate some
sections from the specification in the future.  Start with moving
"Introduction" up to "Unlimited Objects" to a new file.

Update #3836.
---
 .../{configuring_a_system.rst => config/index.rst} | 409 +---
 c-user/config/intro.rst| 412 +
 c-user/index.rst   |   2 +-
 3 files changed, 415 insertions(+), 408 deletions(-)
 rename c-user/{configuring_a_system.rst => config/index.rst} (88%)
 create mode 100644 c-user/config/intro.rst

diff --git a/c-user/configuring_a_system.rst b/c-user/config/index.rst
similarity index 88%
rename from c-user/configuring_a_system.rst
rename to c-user/config/index.rst
index 75b1c7b..982a258 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/config/index.rst
@@ -9,414 +9,9 @@
 Configuring a System
 
 
-Introduction
-
-
-RTEMS must be configured for an application.  This configuration encompasses a
-variety of information including the length of each clock tick, the maximum
-number of each information RTEMS object that can be created, the application
-initialization tasks, the task scheduling algorithm to be used, and the device
-drivers in the application.
-
-Although this information is contained in data structures that are used by
-RTEMS at system initialization time, the data structures themselves must not be
-generated by hand. RTEMS provides a set of macros system which provides a
-simple standard mechanism to automate the generation of these structures.
-
-.. index:: confdefs.h
-.. index:: 
-
-The RTEMS header file  is at the core of the automatic
-generation of system configuration. It is based on the idea of setting macros
-which define configuration parameters of interest to the application and
-defaulting or calculating all others. This variety of macros can automatically
-produce all of the configuration data required for an RTEMS application.
-
-.. sidebar: Trivia:
-
-  The term ``confdefs`` is shorthand for a *Configuration Defaults*.
-
-As a general rule, application developers only specify values for the
-configuration parameters of interest to them. They define what resources or
-features they require. In most cases, when a parameter is not specified, it
-defaults to zero (0) instances, a standards compliant value, or disabled as
-appropriate. For example, by default there will be 256 task priority levels but
-this can be lowered by the application. This number of priority levels is
-required to be compliant with the RTEID/ORKID standards upon which the Classic
-API is based. There are similar cases where the default is selected to be
-compliant with the POSIX standard.
-
-For each configuration parameter in the configuration tables, the macro
-corresponding to that field is discussed. The RTEMS Maintainers expect that all
-systems can be easily configured using the  mechanism and
-that using this mechanism will avoid internal RTEMS configuration changes
-impacting applications.
-
-Default Value Selection Philosophy
-==
-
-The user should be aware that the defaults are intentionally set as low as
-possible.  By default, no application resources are configured.  The
- file ensures that at least one application task or
-thread is configured and that at least one of the initialization task/thread
-tables is configured.
-
-.. _Sizing the RTEMS Workspace:
-
-Sizing the RTEMS Workspace
-==
-
-The RTEMS Workspace is a user-specified block of memory reserved for use by
-RTEMS.  The application should NOT modify this memory.  This area consists
-primarily of the RTEMS data structures whose exact size depends upon the values
-specified in the Configuration Table.  In addition, task stacks and floating
-point context areas are dynamically allocated from the RTEMS Workspace.
-
-The  mechanism calculates the size of the RTEMS Workspace
-automatically.  It assumes that all tasks are floating point and that all will
-be allocated the minimum stack space.  This calculation includes the amount of
-memory that will be allocated for internal use by RTEMS. The automatic
-calculation may underestimate the workspace size truly needed by the
-application, in which case one can use the ``CONFIGURE_MEMORY_OVERHEAD`` macro
-to add a value to the estimate. See :ref:`Specify Memory Overhead` for more
-details.
-
-The memory area for the RTEMS Workspace is determined by the BSP.  In case the
-RTEMS Workspace is too large for the available memory, then a fatal run-time
-error occurs and the system terminates.
-
-The file  will calculate the value of the
-``work_space_size`` parameter of the Configuration Table. There are many
-parameters the application developer can specify to help 
-in its calculations.  Correctly specifying the application requirements via
-parameters such as ``CONFIGURE_EXTRA_TASK_STACKS`` and

[PATCH 12/20] c-user: Move "Idle Task Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/idle-task-config | 96 ++
 c-user/config/index.rst| 94 +
 2 files changed, 97 insertions(+), 93 deletions(-)
 create mode 100644 c-user/config/idle-task-config

diff --git a/c-user/config/idle-task-config b/c-user/config/idle-task-config
new file mode 100644
index 000..ef8b192
--- /dev/null
+++ b/c-user/config/idle-task-config
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Idle Task Configuration
+===
+
+This section defines the IDLE task related configuration parameters supported
+by .
+
+.. index:: CONFIGURE_IDLE_TASK_BODY
+
+.. _CONFIGURE_IDLE_TASK_BODY:
+
+CONFIGURE_IDLE_TASK_BODY
+
+
+CONSTANT:
+``CONFIGURE_IDLE_TASK_BODY``
+
+DATA TYPE:
+Function pointer.
+
+RANGE:
+Undefined or valid function pointer.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+``CONFIGURE_IDLE_TASK_BODY`` is set to the function name corresponding to
+the application specific IDLE thread body.  If not specified, the BSP or
+RTEMS default IDLE thread body will be used.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION
+
+.. _CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION:
+
+CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION
+---
+
+CONSTANT:
+``CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default, the user is assumed to provide one or more
+initialization tasks.
+
+DESCRIPTION:
+``CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`` is set to indicate that the
+user has configured *NO* user initialization tasks or threads and that the
+user provided IDLE task will perform application initialization and then
+transform itself into an IDLE task.
+
+NOTES:
+If you use this option be careful, the user IDLE task *CANNOT* block at all
+during the initialization sequence.  Further, once application
+initialization is complete, it must make itself preemptible and enter an
+IDLE body loop.
+
+The IDLE task must run at the lowest priority of all tasks in the system.
+
+.. index:: CONFIGURE_IDLE_TASK_STACK_SIZE
+
+.. _CONFIGURE_IDLE_TASK_STACK_SIZE:
+
+CONFIGURE_IDLE_TASK_STACK_SIZE
+--
+
+CONSTANT:
+``CONFIGURE_IDLE_TASK_STACK_SIZE``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Undefined or positive.
+
+DEFAULT VALUE:
+The default value is RTEMS_MINIMUM_STACK_SIZE.
+
+DESCRIPTION:
+``CONFIGURE_IDLE_TASK_STACK_SIZE`` is set to the desired stack size for the
+IDLE task.
+
+NOTES:
+None.
diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index 821263d..ca10d4a 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -22,99 +22,7 @@ Configuring a System
 filesystem-config
 bdbuf-config
 bsp-config
-
-Idle Task Configuration
-===
-
-This section defines the IDLE task related configuration parameters supported
-by .
-
-.. index:: CONFIGURE_IDLE_TASK_BODY
-
-.. _CONFIGURE_IDLE_TASK_BODY:
-
-CONFIGURE_IDLE_TASK_BODY
-
-
-CONSTANT:
-``CONFIGURE_IDLE_TASK_BODY``
-
-DATA TYPE:
-Function pointer.
-
-RANGE:
-Undefined or valid function pointer.
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-``CONFIGURE_IDLE_TASK_BODY`` is set to the function name corresponding to
-the application specific IDLE thread body.  If not specified, the BSP or
-RTEMS default IDLE thread body will be used.
-
-NOTES:
-None.
-
-.. index:: CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION
-
-.. _CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION:
-
-CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION

-
-CONSTANT:
-``CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This is not defined by default, the user is assumed to provide one or more
-initialization tasks.
-
-DESCRIPTION:
-``CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`` is set to indicate that the
-user has configured *NO* user initialization tasks or threads and that the
-user provided IDLE task will perform application initialization and then
-transform itself into an IDLE task.
-
-NOTES:
-If you use this option be careful, the user IDLE task *CANNOT* block at all
-during the initialization sequence.  Further, once application
-initialization is complete, it must make itself preemptible and enter an
-IDLE body loop.
-
-The IDLE task must run at the lowest priority of all tasks in the system.
-
-.. index:: CONFIGURE_IDLE_TASK_STACK_S

[PATCH 10/20] c-user: Move "Block Device Cache Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/bdbuf-config.rst | 338 +
 c-user/config/index.rst| 336 +---
 2 files changed, 339 insertions(+), 335 deletions(-)
 create mode 100644 c-user/config/bdbuf-config.rst

diff --git a/c-user/config/bdbuf-config.rst b/c-user/config/bdbuf-config.rst
new file mode 100644
index 000..011d4ee
--- /dev/null
+++ b/c-user/config/bdbuf-config.rst
@@ -0,0 +1,338 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Block Device Cache Configuration
+
+
+This section defines Block Device Cache (bdbuf) related configuration
+parameters.
+
+.. index:: CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
+
+.. _CONFIGURE_APPLICATION_NEEDS_LIBBLOCK:
+
+CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
+
+
+CONSTANT:
+``CONFIGURE_APPLICATION_NEEDS_LIBBLOCK``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+Provides a Block Device Cache configuration.
+
+NOTES:
+Each option of the Block Device Cache configuration can be explicitly set
+by the user with the configuration options below.  The Block Device Cache
+is used for example by the RFS and DOSFS file systems.
+
+.. index:: CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
+
+.. _CONFIGURE_BDBUF_CACHE_MEMORY_SIZE:
+
+CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
+-
+
+CONSTANT:
+``CONFIGURE_BDBUF_CACHE_MEMORY_SIZE``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Positive.
+
+DEFAULT VALUE:
+The default value is 32768 bytes.
+
+DESCRIPTION:
+Size of the cache memory in bytes.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_BDBUF_BUFFER_MAX_SIZE
+
+.. _CONFIGURE_BDBUF_BUFFER_MAX_SIZE:
+
+CONFIGURE_BDBUF_BUFFER_MAX_SIZE
+---
+
+CONSTANT:
+``CONFIGURE_BDBUF_BUFFER_MAX_SIZE``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+It must be positive and an integral multiple of the buffer minimum size.
+
+DEFAULT VALUE:
+The default value is 4096 bytes.
+
+DESCRIPTION:
+Defines the maximum size of a buffer in bytes.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_BDBUF_BUFFER_MIN_SIZE
+
+.. _CONFIGURE_BDBUF_BUFFER_MIN_SIZE:
+
+CONFIGURE_BDBUF_BUFFER_MIN_SIZE
+---
+
+CONSTANT:
+``CONFIGURE_BDBUF_BUFFER_MIN_SIZE``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Positive.
+
+DEFAULT VALUE:
+The default value is 512 bytes.
+
+DESCRIPTION:
+Defines the minimum size of a buffer in bytes.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS
+
+.. _CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS:
+
+CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS
+-
+
+CONSTANT:
+``CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Positive.
+
+DEFAULT VALUE:
+The default value is 0.
+
+DESCRIPTION:
+Defines the maximum blocks per read-ahead request.
+
+NOTES:
+A value of 0 disables the read-ahead task (default).  The read-ahead task
+will issue speculative read transfers if a sequential access pattern is
+detected.  This can improve the performance on some systems.
+
+.. index:: CONFIGURE_BDBUF_MAX_WRITE_BLOCKS
+
+.. _CONFIGURE_BDBUF_MAX_WRITE_BLOCKS:
+
+CONFIGURE_BDBUF_MAX_WRITE_BLOCKS
+
+
+CONSTANT:
+``CONFIGURE_BDBUF_MAX_WRITE_BLOCKS``
+
+DATA TYPE:
+Unsigned integer (``uint32_t``).
+
+RANGE:
+Positive.
+
+DEFAULT VALUE:
+The default value is 16.
+
+DESCRIPTION:
+Defines the maximum blocks per write request.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY
+
+.. _CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY:
+
+CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY
+
+
+CONSTANT:
+``CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY``
+
+DATA TYPE:
+Task priority (``rtems_task_priority``).
+
+RANGE:
+Valid task priority.
+
+DEFAULT VALUE:
+The default value is 15.
+
+DESCRIPTION:
+Defines the read-ahead task priority.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_BDBUF_TASK_STACK_SIZE
+
+.. _CONFIGURE_BDBUF_TASK_STACK_SIZE:
+
+CONFIGURE_BDBUF_TASK_STACK_SIZE
+---
+
+CONSTANT:
+``CONFIGURE_BDBUF_TASK_STACK_SIZE``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Zero or positive.
+
+DEFAULT VALUE:
+The default value is RTEMS_MINIMUM_STACK_SIZE.
+
+DESCRIPTION:
+Defines the task stack size of the Block Device Cache tasks in bytes.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_SWAPOUT_BLOCK_HOLD
+
+.. _CONFIGURE_SWAPOUT_BLOCK_HOLD:
+
+CONFIGURE_SWAPOUT_BLOCK_HOLD
+
+
+CONSTANT:
+``CONFIGURE_SWAPOUT_BLOCK_HOLD``
+
+D

[PATCH 06/20] c-user: Move "POSIX Initialization Thread Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst| 103 +---
 c-user/config/posix-init-thread-config.rst | 105 +
 2 files changed, 106 insertions(+), 102 deletions(-)
 create mode 100644 c-user/config/posix-init-thread-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index fc76fca..4333495 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -16,108 +16,7 @@ Configuring a System
 classic-api-config
 classic-init-task-config
 posix-api-config
-
-POSIX Initialization Thread Configuration
-=
-
-The  configuration system can automatically generate a
-POSIX Initialization Threads Table named ``POSIX_Initialization_threads`` with
-a single entry.  The following parameters control the generation of that table.
-
-.. index:: CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT
-
-.. _CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT:
-
-CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT

-
-CONSTANT:
-``CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT``
-
-DATA TYPE:
-POSIX thread function pointer (``void *(*entry_point)(void *)``).
-
-RANGE:
-Undefined or a valid POSIX thread function pointer.
-
-DEFAULT VALUE:
-The default value is ``POSIX_Init``.
-
-DESCRIPTION:
-``CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT`` is the entry point
-(a.k.a. function name) of the single initialization thread defined by the
-POSIX API Initialization Threads Table.
-
-NOTES:
-The user must implement the function ``POSIX_Init`` or the function name
-provided in this configuration parameter.
-
-.. index:: CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE
-
-.. _CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE:
-
-CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE
---
-
-CONSTANT:
-``CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE``
-
-DATA TYPE:
-Unsigned integer (``size_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is 2 \* RTEMS_MINIMUM_STACK_SIZE.
-
-DESCRIPTION:
-``CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE`` is the stack size of the single
-initialization thread defined by the POSIX API Initialization Threads
-Table.
-
-NOTES:
-If the stack size specified is greater than the configured minimum, it must
-be accounted for in ``CONFIGURE_EXTRA_TASK_STACKS``.  See :ref:`Reserve
-Task/Thread Stack Memory Above Minimum` for more information about
-``CONFIGURE_EXTRA_TASK_STACKS``.
-
-.. index:: CONFIGURE_POSIX_INIT_THREAD_TABLE
-
-.. _CONFIGURE_POSIX_INIT_THREAD_TABLE:
-
-CONFIGURE_POSIX_INIT_THREAD_TABLE
--
-
-CONSTANT:
-``CONFIGURE_POSIX_INIT_THREAD_TABLE``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This field is not defined by default, as the user MUST select their own API
-for initialization tasks.
-
-DESCRIPTION:
-``CONFIGURE_POSIX_INIT_THREAD_TABLE`` is defined if the user wishes to use
-a POSIX API Initialization Threads Table.  The table built by
- specifies the parameters for a single thread. This
-is sufficient for applications which initialization the system from a
-single task.
-
-By default, this field is not defined as the user MUST select their own API
-for initialization tasks.
-
-NOTES:
-The application may choose to use the initialization tasks or threads table
-from another API.
-
-A compile time error will be generated if the user does not configure any
-initialization tasks or threads.
+posix-init-thread-config
 
 Task Stack Allocator Configuration
 ==
diff --git a/c-user/config/posix-init-thread-config.rst 
b/c-user/config/posix-init-thread-config.rst
new file mode 100644
index 000..04027fa
--- /dev/null
+++ b/c-user/config/posix-init-thread-config.rst
@@ -0,0 +1,105 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+POSIX Initialization Thread Configuration
+=
+
+The  configuration system can automatically generate a
+POSIX Initialization Threads Table named ``POSIX_Initialization_threads`` with
+a single entry.  The following parameters control the generation of that table.
+
+.. index:: CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT
+
+.. _CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT:
+
+CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT
+---
+
+CONSTANT:
+``CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT``
+
+DATA TYPE:
+POSIX thread function pointer (``void *(*entry_point)(void *)``).
+
+RANGE:
+Undefined or a valid POSIX thread function pointer.
+
+DEFAULT VALUE:
+The default value is ``POSIX_Init``.
+
+DESCRIPTION:
+``CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT`` is the entry point
+(a.k.a. function name) of the single initialization thr

[PATCH 08/20] c-user: Move "Message Queue Buffer Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst  | 91 +--
 c-user/config/msgq-buffer-config.rst | 93 
 2 files changed, 94 insertions(+), 90 deletions(-)
 create mode 100644 c-user/config/msgq-buffer-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index c99a3cf..5f5d3c1 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -18,96 +18,7 @@ Configuring a System
 posix-api-config
 posix-init-thread-config
 stack-alloc-config
-
-Message Queue Buffer Configuration
-==
-
-This section describes the configuration parameters related to specifying the
-amount of memory reserved for message queue message buffers.  See
-:ref:`CONFIGURE_MAXIMUM_MESSAGE_QUEUES` and
-:ref:`CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES`.
-
-.. index:: CONFIGURE_MESSAGE_BUFFER_MEMORY
-.. index:: configure message queue buffer memory
-
-.. _CONFIGURE_MESSAGE_BUFFER_MEMORY:
-
-CONFIGURE_MESSAGE_BUFFER_MEMORY

-
-CONSTANT:
-``CONFIGURE_MESSAGE_BUFFER_MEMORY``
-
-DATA TYPE:
-integer summation macro
-
-RANGE:
-undefined (zero) or calculation resulting in a positive integer
-
-DEFAULT VALUE:
-This is not defined by default, and zero (0) memory is reserved.
-
-DESCRIPTION:
-This macro is set to the number of bytes the application requires to be
-reserved for pending Classic API Message Queue buffers.
-
-NOTES:
-The following illustrates how the help macro
-:ref:`CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE` can be used to assist in
-calculating the message buffer memory required.  In this example, there are
-two message queues used in this application.  The first message queue has
-maximum of 24 pending messages with the message structure defined by the
-type ``one_message_type``.  The other message queue has maximum of 500
-pending messages with the message structure defined by the type
-``other_message_type``.
-
-.. code-block:: c
-
-#define CONFIGURE_MESSAGE_BUFFER_MEMORY \
-(CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \
- 24, sizeof(one_message_type) \
- ) + \
- CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \
- 500, sizeof(other_message_type) \
- )
-
-.. index:: CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE
-.. index:: memory for a single message queue's buffers
-
-.. _CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE:
-
-CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE

-
-CONSTANT:
-``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(max_messages, size_per)``
-
-DATA TYPE:
-Unsigned integer (``size_t``).
-
-RANGE:
-Positive.
-
-DEFAULT VALUE:
-The default value is None.
-
-DESCRIPTION:
-This is a helper macro which is used to assist in computing the total
-amount of memory required for message buffers.  Each message queue will
-have its own configuration with maximum message size and maximum number of
-pending messages.
-
-The interface for this macro is as follows:
-
-.. code-block:: c
-
-CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(max_messages, size_per)
-
-Where ``max_messages`` is the maximum number of pending messages and
-``size_per`` is the size in bytes of the user message.
-
-NOTES:
-This macro is only used in support of 
:ref:`CONFIGURE_MESSAGE_BUFFER_MEMORY`.
+msgq-buffer-config
 
 Filesystem Configuration
 
diff --git a/c-user/config/msgq-buffer-config.rst 
b/c-user/config/msgq-buffer-config.rst
new file mode 100644
index 000..8d40149
--- /dev/null
+++ b/c-user/config/msgq-buffer-config.rst
@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Message Queue Buffer Configuration
+==
+
+This section describes the configuration parameters related to specifying the
+amount of memory reserved for message queue message buffers.  See
+:ref:`CONFIGURE_MAXIMUM_MESSAGE_QUEUES` and
+:ref:`CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES`.
+
+.. index:: CONFIGURE_MESSAGE_BUFFER_MEMORY
+.. index:: configure message queue buffer memory
+
+.. _CONFIGURE_MESSAGE_BUFFER_MEMORY:
+
+CONFIGURE_MESSAGE_BUFFER_MEMORY
+---
+
+CONSTANT:
+``CONFIGURE_MESSAGE_BUFFER_MEMORY``
+
+DATA TYPE:
+integer summation macro
+
+RANGE:
+undefined (zero) or calculation resulting in a positive integer
+
+DEFAULT VALUE:
+This is not defined by default, and zero (0) memory is reserved.
+
+DESCRIPTION:
+This macro is set to the number of bytes the application requires to be
+reserved for pending Classic API Message Queue buffers.
+
+NOTES:
+The following illustrates how the help macro
+:ref:`CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE` can be used to assist in
+calculating the message buffe

[PATCH 05/20] c-user: Move "POSIX API Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst| 250 +---
 c-user/config/posix-api-config.rst | 252 +
 2 files changed, 253 insertions(+), 249 deletions(-)
 create mode 100644 c-user/config/posix-api-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index 254deed..fc76fca 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -15,255 +15,7 @@ Configuring a System
 general-config
 classic-api-config
 classic-init-task-config
-
-POSIX API Configuration
-===
-
-The parameters in this section are used to configure resources for the POSIX
-API supported by RTEMS.  Most POSIX API objects are available by default since
-RTEMS 5.1.  The queued signals and timers are only available if RTEMS was built
-with the ``--enable-posix`` build configuration option.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_KEYS
-
-.. _CONFIGURE_MAXIMUM_POSIX_KEYS:
-
-CONFIGURE_MAXIMUM_POSIX_KEYS
-
-
-CONSTANT:
-``CONFIGURE_MAXIMUM_POSIX_KEYS``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is 0.
-
-DESCRIPTION:
-``CONFIGURE_MAXIMUM_POSIX_KEYS`` is the maximum number of POSIX API Keys
-that can be concurrently active.
-
-NOTES:
-This object class can be configured in unlimited allocation mode.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS
-
-.. _CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS:
-
-CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS

-
-CONSTANT:
-``CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is
-:ref:`CONFIGURE_MAXIMUM_POSIX_KEYS ` *
-:ref:`CONFIGURE_MAXIMUM_TASKS ` +
-:ref:`CONFIGURE_MAXIMUM_POSIX_THREADS `.
-
-DESCRIPTION:
-``CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS`` is the maximum number of key
-value pairs used by POSIX API Keys that can be concurrently active.
-
-NOTES:
-This object class can be configured in unlimited allocation mode.
-
-A key value pair is created by :c:func:`pthread_setspecific` if the value
-is not :c:macro:`NULL`, otherwise it is deleted.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES
-
-.. _CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES:
-
-CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES
---
-
-CONSTANT:
-``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is 0.
-
-DESCRIPTION:
-``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES`` is the maximum number of POSIX
-API Message Queues that can be concurrently active.
-
-NOTES:
-This object class can be configured in unlimited allocation mode.  You have
-to account for the memory used to store the messages of each message queue,
-see :ref:`CONFIGURE_MESSAGE_BUFFER_MEMORY`.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS
-
-.. _CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS:
-
-CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS
---
-
-CONSTANT:
-``CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is 0.
-
-DESCRIPTION:
-``CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS`` is the maximum number of POSIX
-API Queued Signals that can be concurrently active.
-
-NOTES:
-Unlimited objects are not available for queued signals.
-
-Queued signals are only available if RTEMS was built with the
-``--enable-posix`` build configuration option.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_SEMAPHORES
-
-.. _CONFIGURE_MAXIMUM_POSIX_SEMAPHORES:
-
-CONFIGURE_MAXIMUM_POSIX_SEMAPHORES
---
-
-CONSTANT:
-``CONFIGURE_MAXIMUM_POSIX_SEMAPHORES``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is 0.
-
-DESCRIPTION:
-``CONFIGURE_MAXIMUM_POSIX_SEMAPHORES`` is the maximum number of POSIX API
-Named Semaphores that can be concurrently active.
-
-NOTES:
-This object class can be configured in unlimited allocation mode.
-
-Named semaphores are created with ``sem_open()``.  Semaphores initialized
-with ``sem_init()`` are not affected by this configuration option since the
-storage space for these semaphores is user-provided.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_TIMERS
-
-.. _CONFIGURE_MAXIMUM_POSIX_TIMERS:
-
-CONFIGURE_MAXIMUM_POSIX_TIMERS
---
-
-CONSTANT:
-``CONFIGURE_MAXIMUM_POSIX_TIMERS``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Zero or positive.
-
-DEFAULT VALUE:
-The default value is 0.
-
-DESCRIPTION:
-``CONFIGURE_MAXIMUM_POSIX_TIMERS`` is 

[PATCH 09/20] c-user: Move "Filesystem Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/filesystem-config.rst | 547 
 c-user/config/index.rst | 545 +--
 2 files changed, 548 insertions(+), 544 deletions(-)
 create mode 100644 c-user/config/filesystem-config.rst

diff --git a/c-user/config/filesystem-config.rst 
b/c-user/config/filesystem-config.rst
new file mode 100644
index 000..063a8c3
--- /dev/null
+++ b/c-user/config/filesystem-config.rst
@@ -0,0 +1,547 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Filesystem Configuration
+
+
+By default, the In-Memory Filesystem (IMFS) is used as the base filesystem 
(also
+known as root filesystem).  In order to save some memory for your application,
+you can disable the filesystem support with the
+:ref:`CONFIGURE_APPLICATION_DISABLE_FILESYSTEM` configuration option.
+Alternatively, you can strip down the features of the base filesystem with the
+:ref:`CONFIGURE_USE_MINIIMFS_AS_BASE_FILESYSTEM` and
+:ref:`CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM` configuration options.  These
+three configuration options are mutually exclusive.  They are intended for an
+advanced application configuration.
+
+Features of the IMFS can be disabled and enabled with the following
+configuration options:
+
+* :ref:`CONFIGURE_IMFS_DISABLE_CHMOD`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_CHOWN`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_LINK`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_MKNOD`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_MKNOD_FILE`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_MOUNT`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_READDIR`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_READLINK`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_RENAME`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_RMNOD`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_SYMLINK`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_UNMOUNT`
+
+* :ref:`CONFIGURE_IMFS_DISABLE_UTIME`
+
+* :ref:`CONFIGURE_IMFS_ENABLE_MKFIFO`
+
+.. index:: CONFIGURE_APPLICATION_DISABLE_FILESYSTEM
+
+.. _CONFIGURE_APPLICATION_DISABLE_FILESYSTEM:
+
+CONFIGURE_APPLICATION_DISABLE_FILESYSTEM
+
+
+CONSTANT:
+``CONFIGURE_APPLICATION_DISABLE_FILESYSTEM``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default. If no other root file system configuration
+parameters are specified, the IMFS will be used as the root file system.
+
+DESCRIPTION:
+This configuration parameter is defined if the application dose not intend
+to use any kind of filesystem support. This include the device
+infrastructure necessary to support ``printf()``.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_IMFS_ENABLE_MKFIFO
+
+.. _CONFIGURE_IMFS_ENABLE_MKFIFO:
+
+CONFIGURE_IMFS_ENABLE_MKFIFO
+
+
+CONSTANT:
+``CONFIGURE_IMFS_ENABLE_MKFIFO``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+In case this configuration option is defined, then the support to make 
FIFOs
+is enabled in the root IMFS.
+
+.. index:: CONFIGURE_IMFS_DISABLE_CHMOD
+
+.. _CONFIGURE_IMFS_DISABLE_CHMOD:
+
+CONFIGURE_IMFS_DISABLE_CHMOD
+
+
+CONSTANT:
+``CONFIGURE_IMFS_DISABLE_CHMOD``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+In case this configuration option is defined, then the support to change
+the mode is disabled in the root IMFS.
+
+.. index:: CONFIGURE_IMFS_DISABLE_CHOWN
+
+.. _CONFIGURE_IMFS_DISABLE_CHOWN:
+
+CONFIGURE_IMFS_DISABLE_CHOWN
+
+
+CONSTANT:
+``CONFIGURE_IMFS_DISABLE_CHOWN``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+In case this configuration option is defined, then the support to change
+the owner is disabled in the root IMFS.
+
+.. index:: CONFIGURE_IMFS_DISABLE_LINK
+
+.. _CONFIGURE_IMFS_DISABLE_LINK:
+
+CONFIGURE_IMFS_DISABLE_LINK
+---
+
+CONSTANT:
+``CONFIGURE_IMFS_DISABLE_LINK``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+In case this configuration option is defined, then the support to create
+hard links is disabled in the root IMFS.
+
+.. index:: CONFIGURE_IMFS_DISABLE_MKNOD
+
+.. _CONFIGURE_IMFS_DISABLE_MKNOD:
+
+CONFIGURE_IMFS_DISABLE_MKNOD
+
+
+CONSTANT:
+``CONFIGURE_IMFS_DISABLE_MKNOD``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+In case this configuration option is defined, then the support to make
+directorie

[PATCH 19/20] c-user: Move "Ada Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/ada-config.rst | 15 +++
 c-user/config/index.rst  | 13 +
 2 files changed, 16 insertions(+), 12 deletions(-)
 create mode 100644 c-user/config/ada-config.rst

diff --git a/c-user/config/ada-config.rst b/c-user/config/ada-config.rst
new file mode 100644
index 000..49db1f7
--- /dev/null
+++ b/c-user/config/ada-config.rst
@@ -0,0 +1,15 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+.. _ConfigAda:
+
+Ada Configuration
+=
+
+The GNU Ada runtime library (libgnarl) uses threads, mutexes, condition
+variables, and signals from the pthreads API.  It uses also thread-local 
storage
+for the Ada Task Control Block (ATCB).  From these resources only the threads
+need to be accounted for in the configuration.  You should include the Ada 
tasks
+in your setting of the :ref:`CONFIGURE_MAXIMUM_POSIX_THREADS` configuration
+option.
diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index 692a5b0..c9e1c5c 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -28,18 +28,7 @@ Configuring a System
 mpci-config
 libpci-config
 event-record-config
-
-.. _ConfigAda:
-
-Ada Configuration
-=
-
-The GNU Ada runtime library (libgnarl) uses threads, mutexes, condition
-variables, and signals from the pthreads API.  It uses also thread-local 
storage
-for the Ada Task Control Block (ATCB).  From these resources only the threads
-need to be accounted for in the configuration.  You should include the Ada 
tasks
-in your setting of the :ref:`CONFIGURE_MAXIMUM_POSIX_THREADS` configuration
-option.
+ada-config
 
 Obsolete Configuration Options
 ==
-- 
2.16.4

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

[PATCH 11/20] c-user: Move "BSP Related Configuration Options"

[Sebastian Huber]

Update #3836.
---
 c-user/config/bsp-config.rst | 247 +++
 c-user/config/index.rst  | 245 +-
 2 files changed, 248 insertions(+), 244 deletions(-)
 create mode 100644 c-user/config/bsp-config.rst

diff --git a/c-user/config/bsp-config.rst b/c-user/config/bsp-config.rst
new file mode 100644
index 000..a8988e7
--- /dev/null
+++ b/c-user/config/bsp-config.rst
@@ -0,0 +1,247 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+BSP Related Configuration Options
+=
+
+This section describes configuration options related to the BSP.  Some
+configuration options may have a BSP-specific setting which is defined by
+.  The BSP-specific settings can be disabled by the
+:ref:`CONFIGURE_DISABLE_BSP_SETTINGS` configuration option.
+
+.. index:: BSP_IDLE_TASK_BODY
+
+.. _BSP_IDLE_TASK_BODY:
+
+BSP_IDLE_TASK_BODY
+--
+
+CONSTANT:
+``BSP_IDLE_TASK_BODY``
+
+DATA TYPE:
+Function pointer.
+
+RANGE:
+Undefined or valid function pointer.
+
+DEFAULT VALUE:
+This option is BSP specific.
+
+DESCRIPTION:
+If ``BSP_IDLE_TASK_BODY`` is defined by the BSP and
+``CONFIGURE_IDLE_TASK_BODY`` is not defined by the application, then this
+BSP specific idle task body will be used.
+
+NOTES:
+As it has knowledge of the specific CPU model, system controller logic, and
+peripheral buses, a BSP specific IDLE task may be capable of turning
+components off to save power during extended periods of no task activity
+
+.. index:: BSP_IDLE_TASK_STACK_SIZE
+
+.. _BSP_IDLE_TASK_STACK_SIZE:
+
+BSP_IDLE_TASK_STACK_SIZE
+
+
+CONSTANT:
+``BSP_IDLE_TASK_STACK_SIZE``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Undefined or positive.
+
+DEFAULT VALUE:
+This option is BSP specific.
+
+DESCRIPTION:
+If ``BSP_IDLE_TASK_STACK_SIZE`` is defined by the BSP and
+``CONFIGURE_IDLE_TASK_STACK_SIZE`` is not defined by the application, then
+this BSP suggested idle task stack size will be used.
+
+NOTES:
+The order of precedence for configuring the IDLE task stack size is:
+
+- RTEMS default minimum stack size.
+
+- If defined, then ``CONFIGURE_MINIMUM_TASK_STACK_SIZE``.
+
+- If defined, then the BSP specific ``BSP_IDLE_TASK_SIZE``.
+
+- If defined, then the application specified ``CONFIGURE_IDLE_TASK_SIZE``.
+
+.. index:: BSP_INITIAL_EXTENSION
+
+.. _BSP_INITIAL_EXTENSION:
+
+BSP_INITIAL_EXTENSION
+-
+
+CONSTANT:
+``BSP_INITIAL_EXTENSION``
+
+DATA TYPE:
+List of user extension initializers (``rtems_extensions_table``).
+
+RANGE:
+Undefined or a list of user extension initializers.
+
+DEFAULT VALUE:
+This option is BSP specific.
+
+DESCRIPTION:
+If ``BSP_INITIAL_EXTENSION`` is defined by the BSP, then this BSP specific
+initial extension will be placed as the last entry in the initial extension
+table.
+
+NOTES:
+None.
+
+.. index:: BSP_INTERRUPT_STACK_SIZE
+
+.. _BSP_INTERRUPT_STACK_SIZE:
+
+BSP_INTERRUPT_STACK_SIZE
+
+
+CONSTANT:
+``BSP_INTERRUPT_STACK_SIZE``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Undefined or positive.
+
+DEFAULT VALUE:
+This option is BSP specific.
+
+DESCRIPTION:
+If ``BSP_INTERRUPT_STACK_SIZE`` is defined by the BSP and
+``CONFIGURE_INTERRUPT_STACK_SIZE`` is not defined by the application, then
+this BSP specific interrupt stack size will be used.
+
+NOTES:
+None.
+
+.. index:: BSP_MAXIMUM_DEVICES
+
+.. _BSP_MAXIMUM_DEVICES:
+
+BSP_MAXIMUM_DEVICES
+---
+
+CONSTANT:
+``BSP_MAXIMUM_DEVICES``
+
+DATA TYPE:
+Unsigned integer (``size_t``).
+
+RANGE:
+Undefined or positive.
+
+DEFAULT VALUE:
+This option is BSP specific.
+
+DESCRIPTION:
+If ``BSP_MAXIMUM_DEVICES`` is defined by the BSP and
+``CONFIGURE_MAXIMUM_DEVICES`` is not defined by the application, then this
+BSP specific maximum device count will be used.
+
+NOTES:
+This option is specific to the device file system (devFS) and should not be
+confused with the ``CONFIGURE_MAXIMUM_DRIVERS`` option.  This parameter
+only impacts the devFS and thus is only used by  when
+``CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM`` is specified.
+
+.. index:: CONFIGURE_BSP_PREREQUISITE_DRIVERS
+
+.. _CONFIGURE_BSP_PREREQUISITE_DRIVERS:
+
+CONFIGURE_BSP_PREREQUISITE_DRIVERS
+--
+
+CONSTANT:
+``CONFIGURE_BSP_PREREQUISITE_DRIVERS``
+
+DATA TYPE:
+List of device driver initializers (``rtems_driver_address_table``).
+
+RANGE:
+Undefined or array of device drivers.
+
+DEFAULT VALUE:
+This option is BSP specific.
+
+DESCRIPTION:
+``CONFIGURE_BSP_PREREQUISITE_DRIVERS`` is defined if the BSP has device
+drivers it needs to include in the Device Driver Ta

[PATCH 18/20] c-user: Move "Event Recording Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/event-record-config | 61 +++
 c-user/config/index.rst   | 59 +
 2 files changed, 62 insertions(+), 58 deletions(-)
 create mode 100644 c-user/config/event-record-config

diff --git a/c-user/config/event-record-config 
b/c-user/config/event-record-config
new file mode 100644
index 000..6ac0db0
--- /dev/null
+++ b/c-user/config/event-record-config
@@ -0,0 +1,61 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Event Recording Configuration
+=
+
+.. index:: CONFIGURE_RECORD_EXTENSIONS_ENABLED
+
+.. _CONFIGURE_RECORD_EXTENSIONS_ENABLED:
+
+CONFIGURE_RECORD_EXTENSIONS_ENABLED
+---
+
+CONSTANT:
+``CONFIGURE_RECORD_EXTENSIONS_ENABLED``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+If defined and :ref:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS
+` is also defined properly, then the
+record extensions are enabled.
+
+NOTES:
+The record extensions capture thread create, start, restart, delete,
+switch, begin, exitted and terminate events.
+
+.. index:: CONFIGURE_RECORD_PER_PROCESSOR_ITEMS
+
+.. _CONFIGURE_RECORD_PER_PROCESSOR_ITEMS:
+
+CONFIGURE_RECORD_PER_PROCESSOR_ITEMS
+
+
+CONSTANT:
+``CONFIGURE_RECORD_PER_PROCESSOR_ITEMS``
+
+DATA TYPE:
+Unsigned integer (``unsigned int``).
+
+RANGE:
+A power of two greater than or equal to 16.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+If defined, then a record item buffer of the specified item count is
+statically allocated for each configured processor
+(:ref:`CONFIGURE_MAXIMUM_PROCESSORS `).
+
+NOTES:
+None.
diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index e325d15..692a5b0 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -27,64 +27,7 @@ Configuring a System
 device-config
 mpci-config
 libpci-config
-
-Event Recording Configuration
-=
-
-.. index:: CONFIGURE_RECORD_EXTENSIONS_ENABLED
-
-.. _CONFIGURE_RECORD_EXTENSIONS_ENABLED:
-
-CONFIGURE_RECORD_EXTENSIONS_ENABLED

-
-CONSTANT:
-``CONFIGURE_RECORD_EXTENSIONS_ENABLED``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-If defined and :ref:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS
-` is also defined properly, then the
-record extensions are enabled.
-
-NOTES:
-The record extensions capture thread create, start, restart, delete,
-switch, begin, exitted and terminate events.
-
-.. index:: CONFIGURE_RECORD_PER_PROCESSOR_ITEMS
-
-.. _CONFIGURE_RECORD_PER_PROCESSOR_ITEMS:
-
-CONFIGURE_RECORD_PER_PROCESSOR_ITEMS
-
-
-CONSTANT:
-``CONFIGURE_RECORD_PER_PROCESSOR_ITEMS``
-
-DATA TYPE:
-Unsigned integer (``unsigned int``).
-
-RANGE:
-A power of two greater than or equal to 16.
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-If defined, then a record item buffer of the specified item count is
-statically allocated for each configured processor
-(:ref:`CONFIGURE_MAXIMUM_PROCESSORS `).
-
-NOTES:
-None.
+event-record-config
 
 .. _ConfigAda:
 
-- 
2.16.4

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

[PATCH 20/20] c-user: Move "Obsolete Configuration Options"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst   | 222 +
 c-user/config/obsolete-config.rst | 224 ++
 2 files changed, 225 insertions(+), 221 deletions(-)
 create mode 100644 c-user/config/obsolete-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index c9e1c5c..b6eeecd 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -29,224 +29,4 @@ Configuring a System
 libpci-config
 event-record-config
 ada-config
-
-Obsolete Configuration Options
-==
-
-.. index:: CONFIGURE_BDBUF_BUFFER_COUNT
-
-CONFIGURE_BDBUF_BUFFER_COUNT
-
-
-This configuration option was introduced in RTEMS 4.7.0 and is obsolete since
-RTEMS 4.10.0.
-
-.. index:: CONFIGURE_BDBUF_BUFFER_SIZE
-
-CONFIGURE_BDBUF_BUFFER_SIZE

-
-This configuration option was introduced in RTEMS 4.7.0 and is obsolete since
-RTEMS 4.10.0.
-
-.. index:: CONFIGURE_DISABLE_CLASSIC_API_NOTEPADS
-
-CONFIGURE_DISABLE_CLASSIC_API_NOTEPADS
---
-
-This configuration option was introduced in RTEMS 4.9.0 and is obsolete since
-RTEMS 5.1.
-
-.. index:: CONFIGURE_ENABLE_GO
-
-CONFIGURE_ENABLE_GO

-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_GNAT_RTEMS
-
-CONFIGURE_GNAT_RTEMS
-
-
-This configuration option was present in all RTEMS versions since at 1997 and 
is
-obsolete since RTEMS 5.1.  See also :ref:`ConfigAda`.
-
-.. index:: CONFIGURE_HAS_OWN_CONFIGURATION_TABLE
-
-CONFIGURE_HAS_OWN_CONFIGURATION_TABLE
--
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_HAS_OWN_BDBUF_TABLE
-
-CONFIGURE_HAS_OWN_BDBUF_TABLE
--
-
-This configuration option was introduced in RTEMS 4.7.0 and is obsolete since
-RTEMS 4.10.0.
-
-.. index:: CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
-
-CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
--
-
-This configuration option was present in all RTEMS versions since at least 1995
-and is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_HAS_OWN_INIT_TASK_TABLE
-
-.. _CONFIGURE_HAS_OWN_INIT_TASK_TABLE:
-
-CONFIGURE_HAS_OWN_INIT_TASK_TABLE
--
-
-This configuration option was present in all RTEMS versions since at least 1995
-and is obsolete since RTEMS 5.1.  If you used this configuration option or you
-think that there should be a way to configure more than one Classic API
-initialization task, then please ask on the :r:list:`users`.
-
-.. index:: CONFIGURE_HAS_OWN_MOUNT_TABLE
-
-CONFIGURE_HAS_OWN_MOUNT_TABLE
--
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE
-
-CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE

-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
-
-CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
-
-
-This configuration option was present in all RTEMS versions since at 1998 and 
is
-obsolete since RTEMS 5.1.  See also :ref:`CONFIGURE_MAXIMUM_FILE_DESCRIPTORS`.
-
-.. index:: CONFIGURE_MAXIMUM_ADA_TASKS
-
-CONFIGURE_MAXIMUM_ADA_TASKS

-
-This configuration option was present in all RTEMS versions since at 1997 and 
is
-obsolete since RTEMS 5.1.  See also :ref:`ConfigAda`.
-
-.. index:: CONFIGURE_MAXIMUM_FAKE_ADA_TASKS
-
-CONFIGURE_MAXIMUM_FAKE_ADA_TASKS
-
-
-This configuration option was present in all RTEMS versions since at 1997 and 
is
-obsolete since RTEMS 5.1.  See also :ref:`ConfigAda`.
-
-.. index:: CONFIGURE_MAXIMUM_GO_CHANNELS
-
-CONFIGURE_MAXIMUM_GO_CHANNELS
--
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_MAXIMUM_GOROUTINES
-
-CONFIGURE_MAXIMUM_GOROUTINES
-
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_MAXIMUM_MRSP_SEMAPHORES
-
-CONFIGURE_MAXIMUM_MRSP_SEMAPHORES
--
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_NUMBER_OF_TERMIOS_PORTS
-
-CONFIGURE_NUMBER_OF_TERMIOS_PORTS
--
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_BARRIERS
-
-CONFIGURE_MAXIMUM_POSIX_BARRIERS
-
-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES
-
-CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES

-
-This configuration option is obsolete since RTEMS 5.1.
-
-.. index:: CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUE_DESCRIPTORS
-
-CONFIGURE_MA

[PATCH 14/20] c-user: Move "Clustered Scheduler Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/clustered-sched-config.rst | 219 +++
 c-user/config/index.rst  | 217 +-
 2 files changed, 220 insertions(+), 216 deletions(-)
 create mode 100644 c-user/config/clustered-sched-config.rst

diff --git a/c-user/config/clustered-sched-config.rst 
b/c-user/config/clustered-sched-config.rst
new file mode 100644
index 000..0ea2f67
--- /dev/null
+++ b/c-user/config/clustered-sched-config.rst
@@ -0,0 +1,219 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+.. _ConfigurationSchedulersClustered:
+
+Clustered Scheduler Configuration
+=
+
+A clustered scheduler configuration is optional.  It is an advanced
+configuration area and only necessary in specific circumstances.
+
+Clustered scheduling helps to control the worst-case latencies in a
+multiprocessor system (SMP).  The goal is to reduce the amount of shared state
+in the system and thus prevention of lock contention.  Modern multiprocessor
+systems tend to have several layers of data and instruction caches.  With
+clustered scheduling it is possible to honour the cache topology of a system
+and thus avoid expensive cache synchronization traffic.
+
+We have clustered scheduling in case the set of processors of a system is
+partitioned into non-empty pairwise-disjoint subsets.  These subsets are called
+clusters.  Clusters with a cardinality of one are partitions.  Each cluster is
+owned by exactly one scheduler.
+
+In order to use clustered scheduling the application designer has to answer two
+questions.
+
+#. How is the set of processors partitioned into clusters?
+
+#. Which scheduler algorithm is used for which cluster?
+
+The schedulers are statically configured.
+
+Configuration Step 1 - Scheduler Algorithms
+---
+
+Firstly, the application must select which scheduling algorithms are available
+with the following defines
+
+- :ref:`CONFIGURE_SCHEDULER_EDF_SMP `,
+
+- :ref:`CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP 
`,
+
+- :ref:`CONFIGURE_SCHEDULER_PRIORITY_SMP `, 
and
+
+- :ref:`CONFIGURE_SCHEDULER_SIMPLE_SMP `.
+
+This is necessary to calculate the per-thread overhead introduced by the
+scheduler algorithms.  After these definitions the configuration file must
+``#include `` to have access to scheduler-specific
+configuration macros.
+
+It is possible to make more than one scheduler algorithm available to the
+application.  For example a :ref:`Simple Priority SMP Scheduler
+` could be used in a partition for low latency
+tasks in addition to an :ref:`EDF SMP Scheduler ` for a
+general-purpose cluster.  Since the per-thread overhead depends on the
+scheduler algorithm only the scheduler algorithms used by the application
+should be configured.
+
+Configuration Step 2 - Schedulers
+-
+
+Each scheduler needs some data structures.  Use the following macros to create
+the scheduler data structures for a particular scheduler identified in the
+configuration by ``name``.
+
+- ``RTEMS_SCHEDULER_EDF_SMP(name, max_cpu_count)``,
+
+- ``RTEMS_SCHEDULER_PRIORITY_AFFINITY_SMP(name, prio_count)``,
+
+- ``RTEMS_SCHEDULER_PRIORITY_SMP(name, prio_count)``, and
+
+- ``RTEMS_SCHEDULER_SIMPLE_SMP(name)``.
+
+The ``name`` parameter is used as part of a designator for scheduler-specific
+data structures, so the usual C/C++ designator rules apply.  This ``name`` is
+not the scheduler object name.  Additional parameters are scheduler-specific.
+
+.. _ConfigurationSchedulerTable:
+
+Configuration Step 3 - Scheduler Table
+--
+
+The schedulers are registered in the system via the scheduler table.  To
+populate the scheduler table define ``CONFIGURE_SCHEDULER_TABLE_ENTRIES`` to a
+list of the following scheduler table entry initializers
+
+- ``RTEMS_SCHEDULER_TABLE_EDF_SMP(name, obj_name)``,
+
+- ``RTEMS_SCHEDULER_TABLE_PRIORITY_AFFINITY_SMP(name, obj_name)``,
+
+- ``RTEMS_SCHEDULER_TABLE_PRIORITY_SMP(name, obj_name)``, and
+
+- ``RTEMS_SCHEDULER_TABLE_SIMPLE_SMP(name, obj_name)``.
+
+The ``name`` parameter must correspond to the parameter defining the scheduler
+data structures of configuration step 2.  The ``obj_name`` determines the
+scheduler object name and can be used in :ref:`rtems_scheduler_ident()
+` to get the scheduler object identifier.  The scheduler
+index is defined by the index of the scheduler table.  It is a configuration
+error to add a scheduler multiple times to the scheduler table.
+
+Configuration Step 4 - Processor to Scheduler Assignment
+
+
+The last step is to define which processor uses which scheduler.  For this
+purpose a scheduler assignment table must be defined.  The entry count of this
+table must be equal to the configured maximum processors
+(:ref:`CONFIGURE_MAXIMUM_PROCESS

[PATCH 17/20] c-user: Move "PCI Library Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst | 53 +--
 c-user/config/libpci-config.rst | 55 +
 2 files changed, 56 insertions(+), 52 deletions(-)
 create mode 100644 c-user/config/libpci-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index e3c1720..e325d15 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -26,58 +26,7 @@ Configuring a System
 clustered-sched-config
 device-config
 mpci-config
-
-PCI Library Configuration
-=
-
-This section defines the system configuration parameters supported by
-``rtems/confdefs.h`` related to configuring the PCI Library for RTEMS.
-
-The PCI Library startup behaviour can be configured in four different ways
-depending on how ``CONFIGURE_PCI_CONFIG_LIB`` is defined:
-
-.. index:: PCI_LIB_AUTO
-
-``PCI_LIB_AUTO``
-  Used to enable the PCI auto configuration software. PCI will be automatically
-  probed, PCI buses enumerated, all devices and bridges will be initialized
-  using Plug & Play software routines. The PCI device tree will be populated
-  based on the PCI devices found in the system, PCI devices will be configured
-  by allocating address region resources automatically in PCI space according
-  to the BSP or host bridge driver set up.
-
-.. index:: PCI_LIB_READ
-
-``PCI_LIB_READ``
-  Used to enable the PCI read configuration software. The current PCI
-  configuration is read to create the RAM representation (the PCI device tree)
-  of the PCI devices present. PCI devices are assumed to already have been
-  initialized and PCI buses enumerated, it is therefore required that a BIOS or
-  a boot loader has set up configuration space prior to booting into RTEMS.
-
-.. index:: PCI_LIB_STATIC
-
-``PCI_LIB_STATIC``
-  Used to enable the PCI static configuration software. The user provides a PCI
-  tree with information how all PCI devices are to be configured at compile
-  time by linking in a custom ``struct pci_bus pci_hb`` tree. The static PCI
-  library will not probe PCI for devices, instead it will assume that all
-  devices defined by the user are present, it will enumerate the PCI buses and
-  configure all PCI devices in static configuration accordingly. Since probe
-  and allocation software is not needed the startup is faster, has smaller
-  footprint and does not require dynamic memory allocation.
-
-.. index:: PCI_LIB_PERIPHERAL
-
-``PCI_LIB_PERIPHERAL``
-  Used to enable the PCI peripheral configuration. It is similar to
-  ``PCI_LIB_STATIC``, but it will never write the configuration to the PCI
-  devices since PCI peripherals are not allowed to access PCI configuration
-  space.
-
-Note that selecting ``PCI_LIB_STATIC`` or ``PCI_LIB_PERIPHERAL`` but not
-defining ``pci_hb`` will reuslt in link errors. Note also that in these modes
-Plug & Play is not performed.
+libpci-config
 
 Event Recording Configuration
 =
diff --git a/c-user/config/libpci-config.rst b/c-user/config/libpci-config.rst
new file mode 100644
index 000..b62a56c
--- /dev/null
+++ b/c-user/config/libpci-config.rst
@@ -0,0 +1,55 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+PCI Library Configuration
+=
+
+This section defines the system configuration parameters supported by
+``rtems/confdefs.h`` related to configuring the PCI Library for RTEMS.
+
+The PCI Library startup behaviour can be configured in four different ways
+depending on how ``CONFIGURE_PCI_CONFIG_LIB`` is defined:
+
+.. index:: PCI_LIB_AUTO
+
+``PCI_LIB_AUTO``
+  Used to enable the PCI auto configuration software. PCI will be automatically
+  probed, PCI buses enumerated, all devices and bridges will be initialized
+  using Plug & Play software routines. The PCI device tree will be populated
+  based on the PCI devices found in the system, PCI devices will be configured
+  by allocating address region resources automatically in PCI space according
+  to the BSP or host bridge driver set up.
+
+.. index:: PCI_LIB_READ
+
+``PCI_LIB_READ``
+  Used to enable the PCI read configuration software. The current PCI
+  configuration is read to create the RAM representation (the PCI device tree)
+  of the PCI devices present. PCI devices are assumed to already have been
+  initialized and PCI buses enumerated, it is therefore required that a BIOS or
+  a boot loader has set up configuration space prior to booting into RTEMS.
+
+.. index:: PCI_LIB_STATIC
+
+``PCI_LIB_STATIC``
+  Used to enable the PCI static configuration software. The user provides a PCI
+  tree with information how all PCI devices are to be configured at compile
+  time by linking in a custom ``struct pci_bus pci_hb`` tree. The static PCI
+  library will not probe PCI for devices, instead it will assume that all
+  devices defined by the user are present, it will enume

[PATCH 15/20] c-user: Move "Device Driver Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/device-config.rst | 507 
 c-user/config/index.rst | 505 +--
 2 files changed, 508 insertions(+), 504 deletions(-)
 create mode 100644 c-user/config/device-config.rst

diff --git a/c-user/config/device-config.rst b/c-user/config/device-config.rst
new file mode 100644
index 000..38638ce
--- /dev/null
+++ b/c-user/config/device-config.rst
@@ -0,0 +1,507 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Device Driver Configuration
+===
+
+This section defines the configuration parameters related to the automatic
+generation of a Device Driver Table.  As  only is aware
+of a small set of standard device drivers, the generated Device Driver Table is
+suitable for simple applications with no custom device drivers.
+
+Note that network device drivers are not configured in the Device Driver Table.
+
+.. index:: CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+
+.. _CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER:
+
+CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+
+
+CONSTANT:
+``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is defined when the
+application does *NOT* want the Clock Device Driver and is *NOT* using the
+Timer Driver.  The inclusion or exclusion of the Clock Driver must be
+explicit in user applications.
+
+NOTES:
+This configuration parameter is intended to prevent the common user error
+of using the Hello World example as the baseline for an application and
+leaving out a clock tick source.
+
+.. index:: CONFIGURE_APPLICATION_EXTRA_DRIVERS
+
+.. _CONFIGURE_APPLICATION_EXTRA_DRIVERS:
+
+CONFIGURE_APPLICATION_EXTRA_DRIVERS
+---
+
+CONSTANT:
+``CONFIGURE_APPLICATION_EXTRA_DRIVERS``
+
+DATA TYPE:
+device driver entry structures
+
+RANGE:
+Undefined or set of device driver entry structures
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+``CONFIGURE_APPLICATION_EXTRA_DRIVERS`` is defined if the application has
+device drivers it needs to include in the Device Driver Table.  This should
+be defined to the set of device driver entries that will be placed in the
+table at the *END* of the Device Driver Table.
+
+NOTES:
+None.
+
+.. index:: CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
+
+.. _CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER:
+
+CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
+
+
+CONSTANT:
+``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER`` is defined if the application
+wishes to include the Clock Device Driver.
+
+NOTES:
+This device driver is responsible for providing a regular interrupt which
+invokes a clock tick directive.
+
+If neither the Clock Driver not Benchmark Timer is enabled and the
+configuration parameter
+``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is not defined, then a
+compile time error will occur.
+
+.. index:: CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
+
+.. _CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER:
+
+CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
+--
+
+CONSTANT:
+``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` is defined if the
+application wishes to include the Console Device Driver.
+
+NOTES:
+This device driver is responsible for providing the :file:`/dev/console`
+device file.  This device is used to initialize the standard input, output,
+and error file descriptors.
+
+BSPs should be constructed in a manner that allows ``printk()`` to work
+properly without the need for the console driver to be configured.
+
+The
+
+* ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``,
+
+* ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER``, and
+
+* ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_TASK_CONSOLE_DRIVER``
+
+configuration options are mutually exclusive.
+
+.. index:: CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
+
+.. _CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER:
+
+CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
+---
+
+CONSTANT:
+``CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER``
+
+DATA TY

[PATCH 16/20] c-user: Move "Multiprocessing Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/index.rst   | 182 +
 c-user/config/mpci-config.rst | 184 ++
 2 files changed, 185 insertions(+), 181 deletions(-)
 create mode 100644 c-user/config/mpci-config.rst

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index b11a3a5..e3c1720 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -25,187 +25,7 @@ Configuring a System
 general-sched-config
 clustered-sched-config
 device-config
-
-Multiprocessing Configuration
-=
-
-This section defines the multiprocessing related system configuration
-parameters supported by .  They are only used if RTEMS
-was built with the ``--enable-multiprocessing`` build configuration option.
-The multiprocessing (MPCI) support must not be confused with the SMP support.
-
-Additionally, this class of Configuration Constants are only applicable if
-``CONFIGURE_MP_APPLICATION`` is defined.
-
-.. index:: CONFIGURE_MP_APPLICATION
-
-.. _CONFIGURE_MP_APPLICATION:
-
-CONFIGURE_MP_APPLICATION
-
-
-CONSTANT:
-``CONFIGURE_MP_APPLICATION``
-
-DATA TYPE:
-Boolean feature macro.
-
-RANGE:
-Defined or undefined.
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-This configuration parameter must be defined to indicate that the
-application intends to be part of a multiprocessing
-configuration. Additional configuration parameters are assumed to be
-provided.
-
-NOTES:
-This has no impact unless RTEMS was built with the
-``--enable-multiprocessing`` build configuration option.
-
-.. index:: CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS
-
-.. _CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS:
-
-CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS

-
-CONSTANT:
-``CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Positive.
-
-DEFAULT VALUE:
-The default value is 32.
-
-DESCRIPTION:
-``CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS`` is the maximum number of
-concurrently active global objects in a multiprocessor system.
-
-NOTES:
-This value corresponds to the total number of objects which can be created
-with the ``RTEMS_GLOBAL`` attribute.
-
-.. index:: CONFIGURE_MP_MAXIMUM_NODES
-
-.. _CONFIGURE_MP_MAXIMUM_NODES:
-
-CONFIGURE_MP_MAXIMUM_NODES
---
-
-CONSTANT:
-``CONFIGURE_MP_MAXIMUM_NODES``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Positive.
-
-DEFAULT VALUE:
-The default value is 2.
-
-DESCRIPTION:
-``CONFIGURE_MP_MAXIMUM_NODES`` is the maximum number of nodes in a
-multiprocessor system.
-
-NOTES:
-None.
-
-.. index:: CONFIGURE_MP_MAXIMUM_PROXIES
-
-.. _CONFIGURE_MP_MAXIMUM_PROXIES:
-
-CONFIGURE_MP_MAXIMUM_PROXIES
-
-
-CONSTANT:
-``CONFIGURE_MP_MAXIMUM_PROXIES``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Undefined or positive.
-
-DEFAULT VALUE:
-The default value is 32.
-
-DESCRIPTION:
-``CONFIGURE_MP_MAXIMUM_PROXIES`` is the maximum number of concurrently
-active thread/task proxies on this node in a multiprocessor system.
-
-NOTES:
-Since a proxy is used to represent a remote task/thread which is blocking
-on this node. This configuration parameter reflects the maximum number of
-remote tasks/threads which can be blocked on objects on this node.
-
-.. COMMENT: XXX - add xref to proxy discussion in MP chapter
-
-.. index:: CONFIGURE_MP_MPCI_TABLE_POINTER
-
-.. _CONFIGURE_MP_MPCI_TABLE_POINTER:
-
-CONFIGURE_MP_MPCI_TABLE_POINTER

-
-CONSTANT:
-``CONFIGURE_MP_MPCI_TABLE_POINTER``
-
-DATA TYPE:
-pointer to ``rtems_mpci_table``
-
-RANGE:
-undefined or valid pointer
-
-DEFAULT VALUE:
-This is not defined by default.
-
-DESCRIPTION:
-``CONFIGURE_MP_MPCI_TABLE_POINTER`` is the pointer to the MPCI
-Configuration Table.  The default value of this field is``&MPCI_table``.
-
-NOTES:
-RTEMS provides a Shared Memory MPCI Device Driver which can be used on any
-Multiprocessor System assuming the BSP provides the proper set of
-supporting methods.
-
-.. index:: CONFIGURE_MP_NODE_NUMBER
-
-.. _CONFIGURE_MP_NODE_NUMBER:
-
-CONFIGURE_MP_NODE_NUMBER
-
-
-CONSTANT:
-``CONFIGURE_MP_NODE_NUMBER``
-
-DATA TYPE:
-Unsigned integer (``uint32_t``).
-
-RANGE:
-Positive.
-
-DEFAULT VALUE:
-The default value is ``NODE_NUMBER``, which is assumed to be set by the
-compilation environment.
-
-DESCRIPTION:
-``CONFIGURE_MP_NODE_NUMBER`` is the node number of this node in a
-multiprocessor system.
-
-NOTES:
-In the RTEMS Multiprocessing Test Suite, the node number is derived from
-the Makefile variable ``NODE_NUMBER``. The same code is compiled with the
-``NODE_NUMBER`` set to different values. The test programs b

[PATCH 13/20] c-user: Move "General Scheduler Configuration"

[Sebastian Huber]

Update #3836.
---
 c-user/config/general-sched-config.rst | 389 +
 c-user/config/index.rst| 387 +---
 2 files changed, 390 insertions(+), 386 deletions(-)
 create mode 100644 c-user/config/general-sched-config.rst

diff --git a/c-user/config/general-sched-config.rst 
b/c-user/config/general-sched-config.rst
new file mode 100644
index 000..05fce6e
--- /dev/null
+++ b/c-user/config/general-sched-config.rst
@@ -0,0 +1,389 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2010 Gedare Bloom
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+General Scheduler Configuration
+===
+
+This section defines the configuration parameters related to selecting a
+scheduling algorithm for an application.  A scheduler configuration is optional
+and only necessary in very specific circumstances.  A normal application
+configuration does not need any of the configuration options described in this
+section.  By default, the :ref:`Deterministic Priority Scheduler
+` algorithm is used in uniprocessor configurations.  In case
+SMP is enabled and the configured maximum processors
+(:ref:`CONFIGURE_MAXIMUM_PROCESSORS `) is greater
+than one, then the :ref:`Earliest Deadline First (EDF) SMP Scheduler
+` is selected as the default scheduler algorithm.
+
+For the :ref:`schedulers built into
+RTEMS `, the configuration is straightforward.  All that is
+required is to define the configuration macro which specifies which scheduler
+you want for in your application.
+
+The pluggable scheduler interface also enables the user to provide their own
+scheduling algorithm.  If you choose to do this, you must define multiple
+configuration macros.
+
+.. index:: CONFIGURE_SCHEDULER_CBS
+
+.. _CONFIGURE_SCHEDULER_CBS:
+
+CONFIGURE_SCHEDULER_CBS
+---
+
+CONSTANT:
+``CONFIGURE_SCHEDULER_CBS``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+If defined, then the :ref:`Constant Bandwidth Server (CBS) Scheduler
+` algorithm is made available to the application.
+
+NOTES:
+This scheduler configuration option is an advanced configuration option.
+Think twice before you use it.
+
+In case no explicit :ref:`clustered scheduler configuration
+` is present, then it is used as the
+scheduler for exactly one processor.
+
+.. index:: CONFIGURE_SCHEDULER_EDF
+
+.. _CONFIGURE_SCHEDULER_EDF:
+
+CONFIGURE_SCHEDULER_EDF
+---
+
+CONSTANT:
+``CONFIGURE_SCHEDULER_EDF``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+If defined, then the :ref:`Earliest Deadline First (EDF) Scheduler
+` algorithm is made available to the application.
+
+NOTES:
+This scheduler configuration option is an advanced configuration option.
+Think twice before you use it.
+
+In case no explicit :ref:`clustered scheduler configuration
+` is present, then it is used as the
+scheduler for exactly one processor.
+
+.. index:: CONFIGURE_SCHEDULER_EDF_SMP
+
+.. _CONFIGURE_SCHEDULER_EDF_SMP:
+
+CONFIGURE_SCHEDULER_EDF_SMP
+---
+
+CONSTANT:
+``CONFIGURE_SCHEDULER_EDF_SMP``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+This is not defined by default.
+
+DESCRIPTION:
+If defined, then the :ref:`Earliest Deadline First (EDF) SMP Scheduler
+` algorithm is made available to the application.
+
+NOTES:
+This scheduler configuration option is an advanced configuration option.
+Think twice before you use it.
+
+This scheduler algorithm is only available when RTEMS is built with SMP
+support enabled.
+
+In case no explicit :ref:`clustered scheduler configuration
+` is present, then it is used as the
+scheduler for up to 32 processors.
+
+This scheduler algorithm is the default in SMP configurations if
+:ref:`CONFIGURE_MAXIMUM_PROCESSORS ` is
+greater than one.
+
+.. index:: CONFIGURE_SCHEDULER_NAME
+
+.. _CONFIGURE_SCHEDULER_NAME:
+
+CONFIGURE_SCHEDULER_NAME
+
+
+CONSTANT:
+``CONFIGURE_SCHEDULER_NAME``
+
+DATA TYPE:
+RTEMS Name (``rtems_name``).
+
+RANGE:
+Any value.
+
+DEFAULT VALUE:
+The default name is
+
+  - ``"MEDF"`` for the :ref:`EDF SMP Scheduler `,
+  - ``"MPA "`` for the :ref:`Arbitrary Processor Affinity Priority SMP 
Scheduler `,
+  - ``"MPD "`` for the :ref:`Deterministic Priority SMP Scheduler 
`,
+  - ``"MPS "`` for the :ref:`Simple Priority SMP Scheduler 
`,
+  - ``"UCBS"`` for the :ref:`Uniprocessor CBS Scheduler `,
+  - ``"UEDF"`` for the :ref:`Uniprocessor EDF Scheduler `,
+  - ``"UPD "`` for the :ref:`Uniprocessor Deterministic Priority Schedule

ticket #3676 support for aio.h

[Eshan Dhawan]

aio.h is a header related to input and output then why should it be shifted
to newlib?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Suggestion

[Anmol Mishra]

I am drafting a proposal for this, Will submit it as soon as possible,
Possibly by tomorrow. I am getting an idea and I will try to match the
ticket deliverables.

Best Regards
Anmol


On Sat, Feb 29, 2020 at 12:39 AM Amar Takhar  wrote:

> On 2020-02-28 12:39 -0600, Joel Sherrill wrote:
> >
> > We can't blanket upgrade tools to Python 3. The only thing I think we
> agreed
> > when this was recently discussed is that we have categories of tools in
> Python
> > and some have to be compatible with Python 2 and 3.
>
> I wasn't suggesting that.  I said there are tools that don't work in 3 any
> Python 2 program can be written to work in 3 either directly or using the
> six
> library sorry for not being clear!
>
>
> > This would be a good project if there is a summer's worth of work. But
> it
> > could be combined with something if not. And we always like someone to
> submit
> > a "bonus" project idea -- just in case our estimate of the main project
> is
> > woefully over the top and the student kills it in a month. :)
>
> I think it would be a good idea to create a Python RTEMS library that can
> be
> consumed by all our tools and the API tested using pytest.  The goal of
> this
> being the actual tools themselves are a thin layer on top of the library.
> This
> way we can actually test compatibility as required also any  updates to
> the
> library would benefit all the tools we have. I think these 3 items would
> fill up
> an entire summer especially when we include the tests.
>
>
> Something I've been casually working on is an official docker image that
> includes everything anyone would want to work with RTEMS.  That could also
> be
> added to this project as well.  This would build the tools from scratch
> but I
> was going to privately offer images that already have all the tools
> pre-built
> for those who want instant gratification.
>
>
> > Part of this tutorial would involve ASCII screen captures as well as
> > during this process there are expected and unexpected behaviours
> that are
> > best seen visually.
> >
> > This would help someone on-ramping.
>
> Yes I agree a lot of "is this working right" questions come up a lot when
> you're
> working on this because sometimes nothing happens.  Or you run a tool like
> ser2net and are unsure what the expected outcome is.  There are also
> simple
> testing procedures you can do to make sure your FTDI setup is working
> correctly.
> A lot of the frustration can be taken out in getting things started which
> is a
> huge barrier for the entry into RTEMS right now.
>
>
> Amar.
> ___
> 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: ticket #3676 support for aio.h

[Joel Sherrill]

On Mon, Mar 9, 2020, 7:08 AM Eshan Dhawan  wrote:

> aio.h is a header related to input and output then why should it be
> shifted to newlib?
>

We have moved almost every c library and POSIX header file to newlib over
the years. Only a few remain in RTEMS.

Completeness so folks know where to look.

--joel

>
>
>
> ___
> 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: Project Query for #3855 (BSP Buildset for EPICS)

[Mritunjay Sharma]

Thank you, Chris, for such a detailed description of my query.
Yes, sure. I would be more than happy to help with this fantastic idea
proposed by Joel. I think I need to reschedule a few things in my proposal
now. So before things start looking cleaner in my proposal, can we discuss
more on our Bonus Project? Also, do I have to modify the title of the
proposal now on https://devel.rtems.org/wiki/GSoC/2020 ?

Thanks
Mritunjay

On Mon, Mar 9, 2020 at 3:43 AM Chris Johns  wrote:

> On 9/3/20 9:05 am, Joel Sherrill wrote:
> > Do you think it is full summer of work? I am wondering about a bonus
> project if
> > it gets done early. CFS vertical stack might be a good option if no one
> signs up
> > for that.
>
> I was wondering that myself so this is a fantastic idea.
>
> Can we also look at extending the project to create support to generate a,
> PC,
> BBB or RPi ready to run SD card image?
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 2/3] i386: Update build system

[Jan Sommer]

- Update FreeBSD files in libbsd.py
- Introduce path-mappings in waf_libsd.py and libbsd.py for include path
fixes
---
 libbsd.py | 17 +++--
 waf_libbsd.py | 13 +++--
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index d791efe4..3c0b7afe 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -90,6 +90,14 @@ _defaults = {
 'cpu-include-paths': ['rtemsbsd/@CPU@/include',
   'freebsd/sys/@CPU@/include'],
 
+#
+# Map paths based on RTEMS naming to FreeBSD naming.
+#
+'path-mappings': [ # (source, targets)
+# i386
+('freebsd/sys/i386/include', ['freebsd/sys/x86/include', 
'freebsd/sys/i386/include']),
+],
+
 # The path where headers will be copied during build.
 'build-include-path': ['build-include'],
 
@@ -1366,10 +1374,14 @@ class dev_net(builder.Module):
 'sys/net/if_types.h',
 'sys/net/if_var.h',
 'sys/net/vnet.h',
+'sys/net/mp_ring.h',
+'sys/net/iflib_private.h',
 ]
 )
 self.addKernelSpaceSourceFiles(
 [
+'sys/net/iflib.c',
+'sys/net/mp_ring.c',
 'sys/arm/ti/cpsw/if_cpsw.c',
 'sys/dev/ffec/if_ffec.c',
 'sys/dev/mii/mii.c',
@@ -1425,6 +1437,7 @@ class dev_nic(builder.Module):
 'sys/i386/include/specialreg.h',
 'sys/i386/include/md_var.h',
 'sys/i386/include/intr_machdep.h',
+'sys/x86/include/intr_machdep.h',
 'sys/i386/include/cpufunc.h',
 'sys/mips/include/cpufunc.h',
 'sys/mips/include/cpuregs.h',
@@ -2601,7 +2614,7 @@ class pci(builder.Module):
 self.addCPUDependentFreeBSDHeaderFiles(
 [
 'sys/i386/include/_bus.h',
-'sys/i386/include/legacyvar.h',
+'sys/x86/include/legacyvar.h',
 'sys/x86/include/bus.h',
 'sys/x86/include/pci_cfgreg.h',
 ]
@@ -2609,7 +2622,7 @@ class pci(builder.Module):
 self.addCPUDependentFreeBSDSourceFiles(
 [ 'i386' ],
 [
-'sys/i386/i386/legacy.c',
+'sys/x86/x86/legacy.c',
 'sys/x86/pci/pci_bus.c',
 ],
 mm.generator['source']()
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 3a14541a..a98ee3c2 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -210,8 +210,6 @@ class Builder(builder.ModuleManager):
 buildinclude = 'build-include'
 if 'cpu-include-paths' in config:
 cpu = bld.get_env()['RTEMS_ARCH']
-if cpu == "i386":
-cpu = 'x86'
 for i in config['cpu-include-paths']:
 includes += [i.replace('@CPU@', cpu)]
 if 'include-paths' in config:
@@ -222,6 +220,17 @@ class Builder(builder.ModuleManager):
 buildinclude = buildinclude[0]
 includes += [buildinclude]
 
+#
+# Path mappings
+#
+if 'path-mappings' in config:
+for source, target in config['path-mappings']:
+if source in includes:
+target = [target] if isinstance(target, str) else target
+i = includes.index(source)
+includes.remove(source)
+includes[i:i] = target
+
 #
 # Collect the libbsd uses
 #
-- 
2.17.1

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

[PATCH v2 3/3] i386: Port to RTEMS

[Jan Sommer]

- Update imported files to compile rtems-libbsd for i386 based BSPs
---
 freebsd/sbin/sysctl/sysctl.c |8 +
 freebsd/sys/dev/pci/pci_pci.c|2 +
 freebsd/sys/i386/i386/legacy.c   |  381 ---
 freebsd/sys/i386/include/machine/cpufunc.h   |2 +
 freebsd/sys/i386/include/machine/legacyvar.h |   63 -
 freebsd/sys/net/iflib.c  |   26 +
 rtemsbsd/i386/include/machine/clock.h|2 +
 rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0
 rtemsbsd/include/x86/legacyvar.h |1 +
 rtemsbsd/include/x86/specialreg.h| 1074 ++
 rtemsbsd/include/x86/x86_var.h   |  156 +++
 11 files changed, 1271 insertions(+), 444 deletions(-)
 delete mode 100644 freebsd/sys/i386/i386/legacy.c
 delete mode 100644 freebsd/sys/i386/include/machine/legacyvar.h
 create mode 100644 rtemsbsd/i386/include/machine/clock.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
 create mode 100644 rtemsbsd/include/x86/legacyvar.h
 create mode 100644 rtemsbsd/include/x86/specialreg.h
 create mode 100644 rtemsbsd/include/x86/x86_var.h

diff --git a/freebsd/sbin/sysctl/sysctl.c b/freebsd/sbin/sysctl/sysctl.c
index 30ebe5fd..035c1db2 100644
--- a/freebsd/sbin/sysctl/sysctl.c
+++ b/freebsd/sbin/sysctl/sysctl.c
@@ -69,7 +69,9 @@ static const char rcsid[] =
 #endif
 
 #if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
 #include 
+#endif /* __rtems__ */
 #endif
 
 #include 
@@ -832,6 +834,7 @@ S_efi_map(size_t l2, void *p)
 #endif
 
 #if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
 static int
 S_bios_smap_xattr(size_t l2, void *p)
 {
@@ -850,6 +853,7 @@ S_bios_smap_xattr(size_t l2, void *p)
(uintmax_t)smap->length);
return (0);
 }
+#endif /* __rtems__ */
 #endif
 
 static int
@@ -1061,7 +1065,11 @@ show_var(int *oid, int nlen)
 #endif
 #if defined(__amd64__) || defined(__i386__)
else if (strcmp(fmt, "S,bios_smap_xattr") == 0)
+#ifndef __rtems__
func = S_bios_smap_xattr;
+#else /* __rtems__ */
+   func = NULL;
+#endif /* __rtems__ */
 #endif
else {
func = NULL;
diff --git a/freebsd/sys/dev/pci/pci_pci.c b/freebsd/sys/dev/pci/pci_pci.c
index 43c71461..5ba3e9a0 100644
--- a/freebsd/sys/dev/pci/pci_pci.c
+++ b/freebsd/sys/dev/pci/pci_pci.c
@@ -1593,6 +1593,7 @@ pcib_attach_common(device_t dev)
sc->flags |= PCIB_SUBTRACTIVE;
break;
 
+#ifndef __rtems__
 #if !(defined(NEW_PCIB) && defined(PCI_RES_BUS))
 /* Compaq R3000 BIOS sets wrong subordinate bus number. */
 case 0x00dd10de:
@@ -1620,6 +1621,7 @@ pcib_attach_common(device_t dev)
break;
}
 #endif
+#endif /* __rtems__ */
 }
 
 if (pci_msi_device_blacklisted(dev))
diff --git a/freebsd/sys/i386/i386/legacy.c b/freebsd/sys/i386/i386/legacy.c
deleted file mode 100644
index 50fa9aa2..
--- a/freebsd/sys/i386/i386/legacy.c
+++ /dev/null
@@ -1,381 +0,0 @@
-#include 
-
-/*-
- * Copyright 1998 Massachusetts Institute of Technology
- *
- * Permission to use, copy, modify, and distribute this software and
- * its documentation for any purpose and without fee is hereby
- * granted, provided that both the above copyright notice and this
- * permission notice appear in all copies, that both the above
- * copyright notice and this permission notice appear in all
- * supporting documentation, and that the name of M.I.T. not be used
- * in advertising or publicity pertaining to distribution of the
- * software without specific, written prior permission.  M.I.T. makes
- * no representations about the suitability of this software for any
- * purpose.  It is provided "as is" without express or implied
- * warranty.
- * 
- * THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''.  M.I.T. DISCLAIMS
- * ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
- * SHALL M.I.T. 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.
- */
-
-#include 
-__FBSDID("$FreeBSD$");
-
-/*
- * This code implements a system driver for legacy systems that do not
- * support ACPI or when ACPI support is not present in the kernel.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#ifdef DEV_MCA
-#include 
-#endif
-
-#include 
-#include 
-#include 
-
-stat

[PATCH v2 0/3] [5-freebsd-12] Fix compilation for i386

[Jan Sommer]

This is the  backport for the 5-freebsd-12 branch to make rtems-libbsd compile 
for i386 again:
- It also introduces path-mappings to waf_libbsd.py as introduced here:
https://lists.rtems.org/pipermail/devel/2020-February/057457.html

Best regards,

   Jan

Jan Sommer (3):
  i386: Add missing files from FreeBSD
  i386: Update build system
  i386: Port to RTEMS

 freebsd/sbin/sysctl/sysctl.c  |8 +
 freebsd/sys/dev/pci/pci_pci.c |2 +
 freebsd/sys/i386/include/machine/cpufunc.h|2 +
 freebsd/sys/net/iflib.c   | 6773 +
 freebsd/sys/net/iflib_private.h   |   76 +
 freebsd/sys/net/mp_ring.c |  554 ++
 freebsd/sys/net/mp_ring.h |   75 +
 .../sys/x86/include/machine/intr_machdep.h|  180 +
 .../{i386 => x86}/include/machine/legacyvar.h |   26 +-
 freebsd/sys/{i386/i386 => x86/x86}/legacy.c   |   77 +-
 libbsd.py |   17 +-
 rtemsbsd/i386/include/machine/clock.h |2 +
 rtemsbsd/include/rtems/bsd/local/opt_acpi.h   |0
 rtemsbsd/include/x86/legacyvar.h  |1 +
 rtemsbsd/include/x86/specialreg.h | 1074 +++
 rtemsbsd/include/x86/x86_var.h|  156 +
 waf_libbsd.py |   13 +-
 17 files changed, 8997 insertions(+), 39 deletions(-)
 create mode 100644 freebsd/sys/net/iflib.c
 create mode 100644 freebsd/sys/net/iflib_private.h
 create mode 100644 freebsd/sys/net/mp_ring.c
 create mode 100644 freebsd/sys/net/mp_ring.h
 create mode 100644 freebsd/sys/x86/include/machine/intr_machdep.h
 rename freebsd/sys/{i386 => x86}/include/machine/legacyvar.h (76%)
 rename freebsd/sys/{i386/i386 => x86/x86}/legacy.c (89%)
 create mode 100644 rtemsbsd/i386/include/machine/clock.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
 create mode 100644 rtemsbsd/include/x86/legacyvar.h
 create mode 100644 rtemsbsd/include/x86/specialreg.h
 create mode 100644 rtemsbsd/include/x86/x86_var.h

-- 
2.17.1

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

Re: [PATCH] Hello World

[Gedare Bloom]

Hi John,

Thanks. Regarding BeagleBone Black (BBB) you should demonstrate that
you can run RTEMS on the BBB during your proposal prep phase. You will
need to dig to find out what remains to be done in this space. That
said, there is a student with a proposal to advance Flattened Device
Tree support so you would want to avoid that area. It's not clear to
me what else remains to be done that is sufficiently interesting. I'd
like to see if we can support the BBB with RTEMS "legacy" network
stack and lwIP, then it could be a handy board for us as a project to
use to test the networking infrastructure. This is related to
https://devel.rtems.org/ticket/3850

BBB is also a candidate for Controller Area Network (CAN) support (pun
intended). Although we don't have active open project descriptions,
that could be an area for expanding peripheral and library support. It
does require some additional hardware to actually do any testing
though. One can start with Qemu-emulated CAN support, which was added
by a previous RTEMS GSoC student project.

Gedare

On Sun, Mar 8, 2020 at 11:30 AM John kongtcheu  wrote:
>
>
>
> -- Forwarded message -
> From: John kongtcheu 
> Date: Sun, Feb 23, 2020 at 7:19 PM
> Subject: Fwd: [PATCH] Hello World
> To:
> Cc: 
>
>
>
> -- Forwarded message -
> From: John kongtcheu 
> Date: Sun, Feb 23, 2020, 6:53 PM
> Subject: Re: [PATCH] Hello World
> To: Gedare Bloom , , 
>
>
> Hello Gedare
> I'm currently interested in the beagleboard black bsp project as of now. I'm 
> interested in working with the peripherals regarding it.
> Thank you,
>
> On Sun, Feb 23, 2020 at 6:31 PM Gedare Bloom  wrote:
>>
>> Hi John,
>>
>> Thank you. If you're planning to apply for GSoC as a student, please
>> also send me by email your screenshot, CC to j...@rtems.org and
>> chr...@rtems.org
>>
>> Begin to look through the Open Projects for what kinds of projects
>> might interest you, and ask questions here about whether/which
>> projects might be good for you to work on an application.
>>
>> Gedare
>>
>> On Sun, Feb 23, 2020 at 4:20 PM John Kongtcheu  
>> wrote:
>> >
>> > ---
>> >  testsuites/samples/hello/init.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/testsuites/samples/hello/init.c 
>> > b/testsuites/samples/hello/init.c
>> > index 34ded37c55..13aa377d95 100644
>> > --- a/testsuites/samples/hello/init.c
>> > +++ b/testsuites/samples/hello/init.c
>> > @@ -22,7 +22,7 @@ static rtems_task Init(
>> >  {
>> >rtems_print_printer_fprintf_putc(&rtems_test_printer);
>> >TEST_BEGIN();
>> > -  printf( "Hello World\n" );
>> > +  printf( "This is John Kongtcheu's Hello World \n Welcome to RTEMS and 
>> > Google Summer of Code 2020" );
>> >TEST_END();
>> >rtems_test_exit( 0 );
>> >  }
>> > --
>> > 2.17.1
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beaglebone Black USB-OTG/FDT Support GSOC

[Gedare Bloom]

On Sun, Mar 8, 2020 at 3:07 PM Christian Mauderer  wrote:
>
> Hello John,
>
> On 08/03/2020 18:32, John kongtcheu wrote:
> > Thank you for the information. I have already done the hello world
> > project, (I just forwarded it to you to take a look) and I took a break
> > for a little bit, because of school work.
>
> sorry, I missed that mail. Did Gedare or Joel respond to it? Can you
> please add your name to the list here:
>
>   https://devel.rtems.org/wiki/GSoC/2020
>
> > Regarding, working on
> > peripherals I was wondering if there any spots on working on GPIO work
> > and ADC conversion as those are also two jobs I would be greatly
> > interested in.
>
> There are really few peripherals left on BBB. Someone already added a
> GPIO driver some time back. I don't think anything has been done
> regarding ADC. But on the other hand we don't really have an abstraction
> layer for that in RTEMS. Depending on what you plan to add it can be
> anything from not useful at all to a nice part of a project. But you
> have to create some convincing suggestion ;-)
>
I responded on the other thread, but to repeat myself, I think
networking stacks or "exotic" but useful peripheral support (CAN bus
came to mind) could be good BBB projects. And to do a BBB project
requires to have the BBB and able to run RTEMS on it. So we need that
proof in addition to the normal sparc/sis one.

> > Also thank you again for your advice on the USB-OTG work
> > and I will also do my research regarding that topic.
>
> No problem. Don't hesitate to ask if you are stuck somewhere.
>
> Best regards
>
> Christian
>
> >
> > On Sun, Mar 8, 2020 at 12:53 PM Christian Mauderer  > > wrote:
> >
> > On 08/03/2020 15:58, John kongtcheu wrote:
> > > Dear Dev Mailing list,
> > > I'm interested in work regarding peripherals and it seems like working
> > > on the beaglebone black projects would be something I would be be good
> > > at. I have experience working in embedded systems before, and I
> > have my
> > > own BBB. I was curious if there was anyone willing to mentor for this
> > > project or if this project is a good idea at all.
> > > Thank you,
> >
> > Hello John,
> >
> > welcome to RTEMS. Please note that we require students to send in some
> > proof that they can build and run RTEMS on the hardware for the project.
> > See the GSoC Getting Started guide in the wiki.
> >
> > Regarding your suggested project: I would love to see the USB-OTG
> > support working. But note that we already have a proposal to extend the
> > FDT support in BBB. And I'm not sure whether USB-OTG is really enough
> > for a whole GSoC.
> >
> > Adding the USB-OTG support will be mostly a libbsd project and won't be
> > too peripheral oriented. It is more a question about how to analyze how
> > to set up an OTG device in FreeBSD and find out how that can be
> > implemented in RTEMS using libbsd.
> >
> > Maybe you want to start by taking a short look at FreeBSD and how to set
> > up a USB-OTG device there. Depending on that there might could be topics
> > that are similar that would be a good match for the project. For example
> > if it is done via rc.conf: I think there are quite some other stuff that
> > could be added to rc.conf too (e.g. WLAN support; see Trac ticket
> > #3222).
> >
> > Best regards
> >
> > Christian
> >
> ___
> 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: Project Query for #3855 (BSP Buildset for EPICS)

[Gedare Bloom]

On Mon, Mar 9, 2020 at 7:31 AM Mritunjay Sharma
 wrote:
>
> Thank you, Chris, for such a detailed description of my query.
> Yes, sure. I would be more than happy to help with this fantastic idea 
> proposed by Joel. I think I need to reschedule a few things in my proposal 
> now. So before things start looking cleaner in my proposal, can we discuss 
> more on our Bonus Project? Also, do I have to modify the title of the 
> proposal now on https://devel.rtems.org/wiki/GSoC/2020 ?
>
No you don't need to modify the title.

The bonus task would be to carry out similar activities:
* compile CFS by hand, create an RSB "recipe" to build it, then
integrate it with vertical buildset configuration.
* create vertical buildsets for PC, Raspberry Pi, and other boards.
** EPICS community uses many powerpc boards so adding something there
would be good.
** Adding buildsets for the commonly available simulators would be good.

My understanding is that building EPICS7 with RTEMS5 is currently
non-trivial. I have CC'd Heinz Junkes from EPICS community, and he has
agreed intention to co-mentor/advise this project. He is the main
person that has been doing work with EPICS7/RTEMS5 so this will be a
great resource to lean on.

> Thanks
> Mritunjay
>
> On Mon, Mar 9, 2020 at 3:43 AM Chris Johns  wrote:
>>
>> On 9/3/20 9:05 am, Joel Sherrill wrote:
>> > Do you think it is full summer of work? I am wondering about a bonus 
>> > project if
>> > it gets done early. CFS vertical stack might be a good option if no one 
>> > signs up
>> > for that.
>>
>> I was wondering that myself so this is a fantastic idea.
>>
>> Can we also look at extending the project to create support to generate a, 
>> PC,
>> BBB or RPi ready to run SD card image?
>>
>> 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

RTEMS Python Standardization (ticket #3892)

[Anmol Mishra]

Hello,
I proposed the project and after a lot of input, I saw that a project RTEMS
Python Standardization (ticket #3892) has been added to the list.
I have drafted a proposal (It needs a lot of refinement and I seek from
expected mentor and co-mentor in this step)

https://docs.google.com/document/d/1_G0-q7J2b-5kJzZGI32a-KpC6gMzJ1FcNFFTdMCw1c4/edit?usp=sharing

Please consider me a little naive as this is my first proposal, I will try
to match the benchmark in the final proposal, A lot of discussions is to be
done at this stage.

Best Regards
Anmol Mishra
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-examples hello no output devfs

[Sebastian Huber]

On 14/02/2020 16:29, Joel Sherrill wrote:


This filesystem is needed because some applications want no
filesystem but
you require one for device nodes. Even the IMFS is subject to
mallocs which
are undesired in the applications that this was supporting.


Termios uses malloc(), so I don't think this filesystem makes
sense for console drivers. I changed the clock driver to use a
simple system initialization handler. Some time ago I refactored
the IMFS mount operation to use statically allocated data:


https://git.rtems.org/rtems/commit/?id=a9df9169882c564af6714bbf121c278092d3c51c

With a bit of work the IMFS_make_generic_node() can be changed to
not allocate memory and instead use memory provided by the caller.
I spend a considerable amount of time to make it possible that
some time in the future we can have applications with purely
statically allocated resources.


OK. But that's maybe in the indefinite future and you broke something 
today.


I check in the patches which replace the device file system with a 
specialization of the IMFS. You can now install Termios device drivers 
with device filesystem (CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM). 
However, the example still doesn't work since the console driver uses 
link():


#0  rtems_filesystem_default_link (parentloc=0x204144 
<_ISR_Stack_area_begin+2820>, targetloc=0x20417c 
<_ISR_Stack_area_begin+2876>, name=0x11b811 "dev/console", namelen=11) 
at 
/home/EB/sebastian_h/src/rtems/c/src/../../cpukit/libfs/src/defaults/default_link.c:30
#1  0x00101ee4 in link (path1=0x11b820 "/dev/ttyS0", path2=0x11b810 
"/dev/console") at 
/home/EB/sebastian_h/src/rtems/c/src/../../cpukit/libcsupport/src/link.c:47
#2  0x00100a9a in console_initialize (major=0, minor=0, arg=0x0) at 
/home/EB/sebastian_h/src/rtems/c/src/lib/libbsp/arm/realview-pbx-a9/../../../../../../bsps/shared/dev/serial/console-termios-init.c:57
#3  0x00114868 in rtems_io_initialize (major=0, minor=0, argument=0x0) 
at 
/home/EB/sebastian_h/src/rtems/c/src/../../cpukit/sapi/src/ioinitialize.c:36
#4  0x00114802 in _IO_Initialize_all_drivers () at 
/home/EB/sebastian_h/src/rtems/c/src/../../cpukit/sapi/src/io.c:33
#5  0x0011472e in rtems_initialize_executive () at 
/home/EB/sebastian_h/src/rtems/c/src/../../cpukit/sapi/src/exinit.c:128
#6  0x00100c30 in boot_card (cmdline=0x0) at 
/home/EB/sebastian_h/src/rtems/c/src/lib/libbsp/arm/realview-pbx-a9/../../../../../../bsps/shared/start/bootcard.c:55


It is not supported by the device filesystem and the example ends up in 
a fatal error.


What could be an option is to first install the console device under 
"/dev/console" and then try to link it to the other path, if this fails, 
then just continue.


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

Re: RTEMS Python Standardization (ticket #3892)

[Gedare Bloom]

Hello Anmol,

I have provided some feedback on your draft. Please focus on reshaping
your proposal to provide a stronger organization of both your thought
process and your plan for working in the summer. You might like to
review advice in: https://google.github.io/gsocguides/student/

On Mon, Mar 9, 2020 at 12:02 PM Anmol Mishra  wrote:
>
> Hello,
> I proposed the project and after a lot of input, I saw that a project RTEMS 
> Python Standardization (ticket #3892) has been added to the list.
> I have drafted a proposal (It needs a lot of refinement and I seek from 
> expected mentor and co-mentor in this step)
>
> https://docs.google.com/document/d/1_G0-q7J2b-5kJzZGI32a-KpC6gMzJ1FcNFFTdMCw1c4/edit?usp=sharing
>
> Please consider me a little naive as this is my first proposal, I will try to 
> match the benchmark in the final proposal, A lot of discussions is to be done 
> at this stage.
>
> Best Regards
> Anmol Mishra
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Python Standardization (ticket #3892)

[Anmol Mishra]

Sure thing, I have replied and reviewed all your comments. Working on them
and I will restructure it at the earliest. Now I understand google's idea
to get it reviewed by mentors asap, so that reshaping can be done to match
the target in time.

Thanks for your input and time.

Best Regards

On Tue, Mar 10, 2020 at 3:18 AM Gedare Bloom  wrote:

> Hello Anmol,
>
> I have provided some feedback on your draft. Please focus on reshaping
> your proposal to provide a stronger organization of both your thought
> process and your plan for working in the summer. You might like to
> review advice in: https://google.github.io/gsocguides/student/
>
> On Mon, Mar 9, 2020 at 12:02 PM Anmol Mishra 
> wrote:
> >
> > Hello,
> > I proposed the project and after a lot of input, I saw that a project
> RTEMS Python Standardization (ticket #3892) has been added to the list.
> > I have drafted a proposal (It needs a lot of refinement and I seek from
> expected mentor and co-mentor in this step)
> >
> >
> https://docs.google.com/document/d/1_G0-q7J2b-5kJzZGI32a-KpC6gMzJ1FcNFFTdMCw1c4/edit?usp=sharing
> >
> > Please consider me a little naive as this is my first proposal, I will
> try to match the benchmark in the final proposal, A lot of discussions is
> to be done at this stage.
> >
> > Best Regards
> > Anmol Mishra
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel