[PATCH] score: Document _Scheduler_Try_to_schedule_node()

[Sebastian Huber]

---
 cpukit/include/rtems/score/schedulerimpl.h | 44 +-
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/cpukit/include/rtems/score/schedulerimpl.h 
b/cpukit/include/rtems/score/schedulerimpl.h
index e7fbb8b166..8f5e1ba7b8 100644
--- a/cpukit/include/rtems/score/schedulerimpl.h
+++ b/cpukit/include/rtems/score/schedulerimpl.h
@@ -929,6 +929,10 @@ RTEMS_INLINE_ROUTINE Thread_Control 
*_Scheduler_Use_idle_thread(
   return idle;
 }
 
+/**
+ * @brief This enumeration defines what a scheduler should do with a node which
+ * could be scheduled.
+ */
 typedef enum {
   SCHEDULER_TRY_TO_SCHEDULE_DO_SCHEDULE,
   SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE,
@@ -936,21 +940,41 @@ typedef enum {
 } Scheduler_Try_to_schedule_action;
 
 /**
- * @brief Tries to schedule this scheduler node.
- *
- * @param context The scheduler instance context.
- * @param[in, out] node The node which wants to get scheduled.
- * @param idle A potential idle thread used by a potential victim node.
- * @param get_idle_thread Function to get an idle thread.
- *
- * @retval true This node can be scheduled.
- * @retval false This node cannot be scheduled.
+ * @brief Tries to schedule the scheduler node.
+ *
+ * When a scheduler needs to schedule a node, it shall use this function to
+ * determine what it shall do with the node.  The node replaces a victim node 
if
+ * it can be scheduled.
+ *
+ * This function uses the state of the node and the scheduler state of the 
owner
+ * thread to determine what shall be done.  Each scheduler maintains its nodes
+ * independent of other schedulers.  This function ensures that a thread is
+ * scheduled by at most one scheduler.  If a node requires an executing thread
+ * due to some locking protocol and the owner thread is already scheduled by
+ * another scheduler, then an idle thread shall be attached to the node.
+ *
+ * @param[in, out] context is the scheduler instance context.
+ * @param[in, out] node is the node which could be scheduled.
+ * @param idle is an idle thread used by the victim node or NULL.
+ * @param get_idle_thread points to a function to get an idle thread.
+ *
+ * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_SCHEDULE The node shall be scheduled.
+ *
+ * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE The node shall be
+ *   scheduled and the provided idle thread shall be attached to the node.  
This
+ *   action is returned, if the node cannot use the owner thread and shall use
+ *   an idle thread instead.  In this case, the idle thread is provided by the
+ *   victim node.
+ *
+ * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK The node shall be blocked.  This
+ *   action is returned, if the owner thread is already scheduled by another
+ *   scheduler.
  */
 RTEMS_INLINE_ROUTINE Scheduler_Try_to_schedule_action
 _Scheduler_Try_to_schedule_node(
   Scheduler_Context *context,
   Scheduler_Node*node,
-  Thread_Control*idle,
+  const Thread_Control  *idle,
   Scheduler_Get_idle_thread  get_idle_thread
 )
 {
-- 
2.26.2

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

Re: Doubt in scheduler SMP function _Scheduler_SMP_Schedule_highest_ready

[Sebastian Huber]

On 04/08/2020 17:57, Gedare Bloom wrote:

On Tue, Aug 4, 2020 at 8:14 AM Richi Dubey  wrote:

Hi,

I have a quick doubt about the logic in the else part of the 
_Scheduler_SMP_Schedule_highest_ready function.


I'll give my understanding. Only Sebastian really understands this stuff;)


We get the action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK if the node returned by 
get_highest_ready is already SCHEDULED and has a pinning level of 1 (or <=1). 
This means that the highest ready eligible node is already scheduled and pinned to 
a processor.


This means that the highest ready node cannot be scheduled right now,
for some reason. It is the thread that is already scheduled, or the
node is busy helping.


Why do we then change its state to BLOCKED and remove it from the chain of 
ready nodes?


If the thread that owns the node can't be scheduled right now (e.g.,
it is already scheduled on a different node), then the node should be
blocked so we can maybe pick a different node to schedule.


Yes. I tried to improve the documentation a bit:

https://lists.rtems.org/pipermail/devel/2020-August/061144.html

What can be a bit confusing is that we have a scheduled state for 
threads and for scheduler nodes:


/**
 * @brief The thread state with respect to the scheduler.
 */
typedef enum {
  /**
   * @brief This thread is blocked with respect to the scheduler.
   *
   * This thread uses no scheduler nodes.
   */
  THREAD_SCHEDULER_BLOCKED,

  /**
   * @brief This thread is scheduled with respect to the scheduler.
   *
   * This thread executes using one of its scheduler nodes.  This could 
be its

   * own scheduler node or in case it owns resources taking part in the
   * scheduler helping protocol a scheduler node of another thread.
   */
  THREAD_SCHEDULER_SCHEDULED,

  /**
   * @brief This thread is ready with respect to the scheduler.
   *
   * None of the scheduler nodes of this thread is scheduled.
   */
  THREAD_SCHEDULER_READY
} Thread_Scheduler_state;


/**
 * @brief SMP scheduler node states.
 */
typedef enum {
  /**
   * @brief This scheduler node is blocked.
   *
   * A scheduler node is blocked if the corresponding thread is not ready.
   */
  SCHEDULER_SMP_NODE_BLOCKED,

  /**
   * @brief The scheduler node is scheduled.
   *
   * A scheduler node is scheduled if the corresponding thread is ready 
and the
   * scheduler allocated a processor for it.  A scheduled node is 
assigned to

   * exactly one processor.  The count of scheduled nodes in this scheduler
   * instance equals the processor count owned by the scheduler instance.
   */
  SCHEDULER_SMP_NODE_SCHEDULED,

  /**
   * @brief This scheduler node is ready.
   *
   * A scheduler node is ready if the corresponding thread is ready and the
   * scheduler did not allocate a processor for it.
   */
  SCHEDULER_SMP_NODE_READY
} Scheduler_SMP_Node_state;
--
Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH rtems-libbsd 2/2] wscript: add uninstall command

[Vijay Kumar Banerjee]

On Wed, Aug 5, 2020 at 10:34 AM Chris Johns  wrote:
>
> On 5/8/20 1:52 am, Vijay Kumar Banerjee wrote:
> > Hi Chris,
> >
> > Is this patch OK to push to the master?
>
> Yes, please push. I am sorry about the slow review.
>

Thanks for the review. Pushed.

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

[PATCH] psxhdrs_strncpy_fix string_turncation_warning

[Aschref Ben-Thabet]

From: Aschref Ben Thabet 

since we need to test the strncpy function, using a character array with
a fixed array size in this case in place of character pointer can avoid
the string turncation warning.
---
 testsuites/psxtests/psxhdrs/string/stpncpy.c | 8 
 testsuites/psxtests/psxhdrs/string/strncpy.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/testsuites/psxtests/psxhdrs/string/stpncpy.c 
b/testsuites/psxtests/psxhdrs/string/stpncpy.c
index f81752de76..8b3abf747e 100644
--- a/testsuites/psxtests/psxhdrs/string/stpncpy.c
+++ b/testsuites/psxtests/psxhdrs/string/stpncpy.c
@@ -35,17 +35,17 @@
  #endif
 
  #include 
+ #define size 1024
 
  int test( void );
 
  int test( void )
  {
-   char *dest = "Hello world";
-   char *src = "Dude";
-   size_t num = 2;
+   char dest[size] = "Hello world";
+   char src[size] = "Dude";
char *result;
 
-   result = stpncpy( dest, src, num );
+   result = stpncpy( dest, src, sizeof(dest) );
 
return ( result != NULL );
  }
diff --git a/testsuites/psxtests/psxhdrs/string/strncpy.c 
b/testsuites/psxtests/psxhdrs/string/strncpy.c
index 50b64b3d57..73bc480b58 100644
--- a/testsuites/psxtests/psxhdrs/string/strncpy.c
+++ b/testsuites/psxtests/psxhdrs/string/strncpy.c
@@ -35,16 +35,16 @@
  #endif
 
  #include 
-
+ #define size 1024
  int test( void );
 
  int test( void )
  {
-   char *dest = "Hello";
-   char *src = "World";
+   char dest[size] = "Hello";
+   char src[size] = "World";
char *result;
 
-   result = strncpy( dest, src, 3 );
+   result = strncpy( dest, src, sizeof(dest) );
 
return ( result != NULL );
  }
-- 
2.26.2

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

[PATCH] fix Wunused-function deleting unused static functions in dl_tests

[Aschref Ben-Thabet]

From: Aschref Ben Thabet 

the functions dl_close and  dl_call are not needed for this test,
deleting them will avoid the warning of Wunused-function.
---
 testsuites/libtests/dl10/dl-load.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/testsuites/libtests/dl10/dl-load.c 
b/testsuites/libtests/dl10/dl-load.c
index dee1d6e9cc..a9d60a7e5a 100644
--- a/testsuites/libtests/dl10/dl-load.c
+++ b/testsuites/libtests/dl10/dl-load.c
@@ -96,27 +96,6 @@ static void* dl_load_obj(const char* name, bool 
has_unresolved)
   return handle;
 }
 
-static void dl_close (void* handle)
-{
-  int r;
-  printf ("handle: %p closing\n", handle);
-  r = dlclose (handle);
-  if (r != 0)
-printf("dlclose failed: %s\n", dlerror());
-  rtems_test_assert (r == 0);
-}
-
-static int dl_call (void* handle, const char* func)
-{
-  call_sig call = dlsym (handle, func);
-  if (call == NULL)
-  {
-printf("dlsym failed: symbol not found: %s\n", func);
-return 1;
-  }
-  call ();
-  return 0;
-}
 
 int dl_load_test(void)
 {
-- 
2.26.2

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

[PATCH] psxhdrs/strncpy/stpncpy: Fix string turncation warning

[Aschref Ben-Thabet]

From: Aschref Ben Thabet 

Since we need to test the strncpy function, using a character array with
a fixed array size in this case in place of character pointer can avoid
the string turncation warning.
---
 testsuites/psxtests/psxhdrs/string/stpncpy.c | 7 +++
 testsuites/psxtests/psxhdrs/string/strncpy.c | 7 +++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/testsuites/psxtests/psxhdrs/string/stpncpy.c 
b/testsuites/psxtests/psxhdrs/string/stpncpy.c
index f81752de76..f7433a136f 100644
--- a/testsuites/psxtests/psxhdrs/string/stpncpy.c
+++ b/testsuites/psxtests/psxhdrs/string/stpncpy.c
@@ -40,12 +40,11 @@
 
  int test( void )
  {
-   char *dest = "Hello world";
-   char *src = "Dude";
-   size_t num = 2;
+   char src[] = "Dude";
+   char dest[ sizeof( src ) ];
char *result;
 
-   result = stpncpy( dest, src, num );
+   result = stpncpy( dest, src, sizeof( dest ) );
 
return ( result != NULL );
  }
diff --git a/testsuites/psxtests/psxhdrs/string/strncpy.c 
b/testsuites/psxtests/psxhdrs/string/strncpy.c
index 50b64b3d57..e80d6f6e64 100644
--- a/testsuites/psxtests/psxhdrs/string/strncpy.c
+++ b/testsuites/psxtests/psxhdrs/string/strncpy.c
@@ -35,16 +35,15 @@
  #endif
 
  #include 
-
  int test( void );
 
  int test( void )
  {
-   char *dest = "Hello";
-   char *src = "World";
+   char src[] = "World";
+   char dest[ sizeof( src ) ];
char *result;
 
-   result = strncpy( dest, src, 3 );
+   result = strncpy( dest, src, sizeof( dest ) );
 
return ( result != NULL );
  }
-- 
2.26.2

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

Re: [PATCH] psxhdrs/strncpy/stpncpy: Fix string turncation warning

[Joel Sherrill]

These are ok. This code is never executed.and these are reasonable changes.

On Wed, Aug 5, 2020, 6:54 AM Aschref Ben-Thabet <
aschref.ben-tha...@embedded-brains.de> wrote:

> From: Aschref Ben Thabet 
>
> Since we need to test the strncpy function, using a character array with
> a fixed array size in this case in place of character pointer can avoid
> the string turncation warning.
> ---
>  testsuites/psxtests/psxhdrs/string/stpncpy.c | 7 +++
>  testsuites/psxtests/psxhdrs/string/strncpy.c | 7 +++
>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/testsuites/psxtests/psxhdrs/string/stpncpy.c
> b/testsuites/psxtests/psxhdrs/string/stpncpy.c
> index f81752de76..f7433a136f 100644
> --- a/testsuites/psxtests/psxhdrs/string/stpncpy.c
> +++ b/testsuites/psxtests/psxhdrs/string/stpncpy.c
> @@ -40,12 +40,11 @@
>
>   int test( void )
>   {
> -   char *dest = "Hello world";
> -   char *src = "Dude";
> -   size_t num = 2;
> +   char src[] = "Dude";
> +   char dest[ sizeof( src ) ];
> char *result;
>
> -   result = stpncpy( dest, src, num );
> +   result = stpncpy( dest, src, sizeof( dest ) );
>
> return ( result != NULL );
>   }
> diff --git a/testsuites/psxtests/psxhdrs/string/strncpy.c
> b/testsuites/psxtests/psxhdrs/string/strncpy.c
> index 50b64b3d57..e80d6f6e64 100644
> --- a/testsuites/psxtests/psxhdrs/string/strncpy.c
> +++ b/testsuites/psxtests/psxhdrs/string/strncpy.c
> @@ -35,16 +35,15 @@
>   #endif
>
>   #include 
> -
>   int test( void );
>
>   int test( void )
>   {
> -   char *dest = "Hello";
> -   char *src = "World";
> +   char src[] = "World";
> +   char dest[ sizeof( src ) ];
> char *result;
>
> -   result = strncpy( dest, src, 3 );
> +   result = strncpy( dest, src, sizeof( dest ) );
>
> return ( result != NULL );
>   }
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] eng: Refer to the rtems-central repository

[Sebastian Huber]

Close #4043.
---
 eng/req/howto.rst | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/eng/req/howto.rst b/eng/req/howto.rst
index 9a28427..c539563 100644
--- a/eng/req/howto.rst
+++ b/eng/req/howto.rst
@@ -8,14 +8,13 @@ How-To
 Getting Started
 ---
 
-The RTEMS specification items and qualification tools are work in progress and
-not fully integrated in the RTEMS Project.  The first step to work with the
-RTEMS specification and the corresponding tools is a clone of the following
-repository:
+The RTEMS specification items and qualification tools are work in progress.  
The
+first step to work with the RTEMS specification and the corresponding tools is 
a
+clone of the following repository:
 
 .. code-block:: none
 
-git clone git://git.rtems.org/sebh/rtems-qual.git
+git clone git://git.rtems.org/rtems-central.git
 git submodule init
 git submodule update
 
@@ -23,7 +22,7 @@ The tools need a virtual Python 3 environment. To set it up 
use:
 
 .. code-block:: none
 
-cd rtems-qual
+cd rtems-central
 make env
 
 Each time you want to use one of the tools, you have to activate the
@@ -31,7 +30,7 @@ environment in your shell:
 
 .. code-block:: none
 
-cd rtems-qual
+cd rtems-central
 . env/bin/activate
 
 Glossary Specification
-- 
2.26.2

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

busdma: question about header

[Gabriel.Moyano]

Hello,

After one of the last changes on the file rtems-kernel-bus-dma.c, commit 
5e3780023 on branch 6-freebsd-12, it is not possible to compile the tests for 
i386 because  is not found. How is the best way to solve 
this issue? Adding an #ifndef __i386__? Something like this:

#ifndef __i386__
  #include 
#endif

Maybe this issue affects others architectures too.

Cheers,
Gabriel

--
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
Institute for Software Technology | SC-OSS | Lilienthalplatz 7 | 38108 
Braunschweig  | Germany

Gabriel Moyano | Research Scientist in Onboard Software Systems group


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

Re: busdma: question about header

[Sebastian Huber]

Hello Gabriel,

this should be fixed now.

--
Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH] score: Document _Scheduler_Try_to_schedule_node()

[Richi Dubey]

Thanks for the explanation. I do not understand it right now, but I'm
hoping it'd make sense some time in the future :p

On Wed, Aug 5, 2020 at 12:50 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  cpukit/include/rtems/score/schedulerimpl.h | 44 +-
>  1 file changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/schedulerimpl.h
> b/cpukit/include/rtems/score/schedulerimpl.h
> index e7fbb8b166..8f5e1ba7b8 100644
> --- a/cpukit/include/rtems/score/schedulerimpl.h
> +++ b/cpukit/include/rtems/score/schedulerimpl.h
> @@ -929,6 +929,10 @@ RTEMS_INLINE_ROUTINE Thread_Control
> *_Scheduler_Use_idle_thread(
>return idle;
>  }
>
> +/**
> + * @brief This enumeration defines what a scheduler should do with a node
> which
> + * could be scheduled.
> + */
>  typedef enum {
>SCHEDULER_TRY_TO_SCHEDULE_DO_SCHEDULE,
>SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE,
> @@ -936,21 +940,41 @@ typedef enum {
>  } Scheduler_Try_to_schedule_action;
>
>  /**
> - * @brief Tries to schedule this scheduler node.
> - *
> - * @param context The scheduler instance context.
> - * @param[in, out] node The node which wants to get scheduled.
> - * @param idle A potential idle thread used by a potential victim node.
> - * @param get_idle_thread Function to get an idle thread.
> - *
> - * @retval true This node can be scheduled.
> - * @retval false This node cannot be scheduled.
> + * @brief Tries to schedule the scheduler node.
> + *
> + * When a scheduler needs to schedule a node, it shall use this function
> to
> + * determine what it shall do with the node.  The node replaces a victim
> node if
> + * it can be scheduled.
> + *
> + * This function uses the state of the node and the scheduler state of
> the owner
> + * thread to determine what shall be done.  Each scheduler maintains its
> nodes
> + * independent of other schedulers.  This function ensures that a thread
> is
> + * scheduled by at most one scheduler.  If a node requires an executing
> thread
> + * due to some locking protocol and the owner thread is already scheduled
> by
> + * another scheduler, then an idle thread shall be attached to the node.
> + *
> + * @param[in, out] context is the scheduler instance context.
> + * @param[in, out] node is the node which could be scheduled.
> + * @param idle is an idle thread used by the victim node or NULL.
> + * @param get_idle_thread points to a function to get an idle thread.
> + *
> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_SCHEDULE The node shall be
> scheduled.
> + *
> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE The node shall be
> + *   scheduled and the provided idle thread shall be attached to the
> node.  This
> + *   action is returned, if the node cannot use the owner thread and
> shall use
> + *   an idle thread instead.  In this case, the idle thread is provided
> by the
> + *   victim node.
> + *
> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK The node shall be blocked.
> This
> + *   action is returned, if the owner thread is already scheduled by
> another
> + *   scheduler.
>   */
>  RTEMS_INLINE_ROUTINE Scheduler_Try_to_schedule_action
>  _Scheduler_Try_to_schedule_node(
>Scheduler_Context *context,
>Scheduler_Node*node,
> -  Thread_Control*idle,
> +  const Thread_Control  *idle,
>Scheduler_Get_idle_thread  get_idle_thread
>  )
>  {
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doubt in scheduler SMP function _Scheduler_SMP_Schedule_highest_ready

[Richi Dubey]

Thank you for the clarification.

On Wed, Aug 5, 2020 at 1:00 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/08/2020 17:57, Gedare Bloom wrote:
> > On Tue, Aug 4, 2020 at 8:14 AM Richi Dubey  wrote:
> >> Hi,
> >>
> >> I have a quick doubt about the logic in the else part of the
> _Scheduler_SMP_Schedule_highest_ready function.
> >>
> > I'll give my understanding. Only Sebastian really understands this
> stuff;)
> >
> >> We get the action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK if the node
> returned by get_highest_ready is already SCHEDULED and has a pinning level
> of 1 (or <=1). This means that the highest ready eligible node is already
> scheduled and pinned to a processor.
> >>
> > This means that the highest ready node cannot be scheduled right now,
> > for some reason. It is the thread that is already scheduled, or the
> > node is busy helping.
> >
> >> Why do we then change its state to BLOCKED and remove it from the chain
> of ready nodes?
> >>
> > If the thread that owns the node can't be scheduled right now (e.g.,
> > it is already scheduled on a different node), then the node should be
> > blocked so we can maybe pick a different node to schedule.
>
> Yes. I tried to improve the documentation a bit:
>
> https://lists.rtems.org/pipermail/devel/2020-August/061144.html
>
> What can be a bit confusing is that we have a scheduled state for
> threads and for scheduler nodes:
>
> /**
>   * @brief The thread state with respect to the scheduler.
>   */
> typedef enum {
>/**
> * @brief This thread is blocked with respect to the scheduler.
> *
> * This thread uses no scheduler nodes.
> */
>THREAD_SCHEDULER_BLOCKED,
>
>/**
> * @brief This thread is scheduled with respect to the scheduler.
> *
> * This thread executes using one of its scheduler nodes.  This could
> be its
> * own scheduler node or in case it owns resources taking part in the
> * scheduler helping protocol a scheduler node of another thread.
> */
>THREAD_SCHEDULER_SCHEDULED,
>
>/**
> * @brief This thread is ready with respect to the scheduler.
> *
> * None of the scheduler nodes of this thread is scheduled.
> */
>THREAD_SCHEDULER_READY
> } Thread_Scheduler_state;
>
>
> /**
>   * @brief SMP scheduler node states.
>   */
> typedef enum {
>/**
> * @brief This scheduler node is blocked.
> *
> * A scheduler node is blocked if the corresponding thread is not ready.
> */
>SCHEDULER_SMP_NODE_BLOCKED,
>
>/**
> * @brief The scheduler node is scheduled.
> *
> * A scheduler node is scheduled if the corresponding thread is ready
> and the
> * scheduler allocated a processor for it.  A scheduled node is
> assigned to
> * exactly one processor.  The count of scheduled nodes in this
> scheduler
> * instance equals the processor count owned by the scheduler instance.
> */
>SCHEDULER_SMP_NODE_SCHEDULED,
>
>/**
> * @brief This scheduler node is ready.
> *
> * A scheduler node is ready if the corresponding thread is ready and
> the
> * scheduler did not allocate a processor for it.
> */
>SCHEDULER_SMP_NODE_READY
> } Scheduler_SMP_Node_state;
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Document _Scheduler_Try_to_schedule_node()

[Richi Dubey]

>
> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK The node shall be blocked.
> This
> + *   action is returned, if the owner thread is already scheduled by
> another
> + *   scheduler.

When would this happen? When a thread is getting help from a
different processor that is using a different scheduler, right?
A thread has a node for it in each scheduler, right? ( I saw this in
threadinitialize.c)

  If a node requires an executing thread
> + * due to some locking protocol and the owner thread is already scheduled
> by
> + * another scheduler, then an idle thread shall be attached to the node.

What purpose does this serve?



On Wed, Aug 5, 2020 at 7:02 PM Richi Dubey  wrote:

> Thanks for the explanation. I do not understand it right now, but I'm
> hoping it'd make sense some time in the future :p
>
> On Wed, Aug 5, 2020 at 12:50 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> ---
>>  cpukit/include/rtems/score/schedulerimpl.h | 44 +-
>>  1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/cpukit/include/rtems/score/schedulerimpl.h
>> b/cpukit/include/rtems/score/schedulerimpl.h
>> index e7fbb8b166..8f5e1ba7b8 100644
>> --- a/cpukit/include/rtems/score/schedulerimpl.h
>> +++ b/cpukit/include/rtems/score/schedulerimpl.h
>> @@ -929,6 +929,10 @@ RTEMS_INLINE_ROUTINE Thread_Control
>> *_Scheduler_Use_idle_thread(
>>return idle;
>>  }
>>
>> +/**
>> + * @brief This enumeration defines what a scheduler should do with a
>> node which
>> + * could be scheduled.
>> + */
>>  typedef enum {
>>SCHEDULER_TRY_TO_SCHEDULE_DO_SCHEDULE,
>>SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE,
>> @@ -936,21 +940,41 @@ typedef enum {
>>  } Scheduler_Try_to_schedule_action;
>>
>>  /**
>> - * @brief Tries to schedule this scheduler node.
>> - *
>> - * @param context The scheduler instance context.
>> - * @param[in, out] node The node which wants to get scheduled.
>> - * @param idle A potential idle thread used by a potential victim node.
>> - * @param get_idle_thread Function to get an idle thread.
>> - *
>> - * @retval true This node can be scheduled.
>> - * @retval false This node cannot be scheduled.
>> + * @brief Tries to schedule the scheduler node.
>> + *
>> + * When a scheduler needs to schedule a node, it shall use this function
>> to
>> + * determine what it shall do with the node.  The node replaces a victim
>> node if
>> + * it can be scheduled.
>> + *
>> + * This function uses the state of the node and the scheduler state of
>> the owner
>> + * thread to determine what shall be done.  Each scheduler maintains its
>> nodes
>> + * independent of other schedulers.  This function ensures that a thread
>> is
>> + * scheduled by at most one scheduler.  If a node requires an executing
>> thread
>> + * due to some locking protocol and the owner thread is already
>> scheduled by
>> + * another scheduler, then an idle thread shall be attached to the node.
>> + *
>> + * @param[in, out] context is the scheduler instance context.
>> + * @param[in, out] node is the node which could be scheduled.
>> + * @param idle is an idle thread used by the victim node or NULL.
>> + * @param get_idle_thread points to a function to get an idle thread.
>> + *
>> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_SCHEDULE The node shall be
>> scheduled.
>> + *
>> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE The node shall be
>> + *   scheduled and the provided idle thread shall be attached to the
>> node.  This
>> + *   action is returned, if the node cannot use the owner thread and
>> shall use
>> + *   an idle thread instead.  In this case, the idle thread is provided
>> by the
>> + *   victim node.
>> + *
>> + * @retval SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK The node shall be
>> blocked.  This
>> + *   action is returned, if the owner thread is already scheduled by
>> another
>> + *   scheduler.
>>   */
>>  RTEMS_INLINE_ROUTINE Scheduler_Try_to_schedule_action
>>  _Scheduler_Try_to_schedule_node(
>>Scheduler_Context *context,
>>Scheduler_Node*node,
>> -  Thread_Control*idle,
>> +  const Thread_Control  *idle,
>>Scheduler_Get_idle_thread  get_idle_thread
>>  )
>>  {
>> --
>> 2.26.2
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] smpschededf02: Document reset() function

[Richi Dubey]

I would. Thank you.

On Wed, Aug 5, 2020 at 10:24 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/08/2020 16:23, Richi Dubey wrote:
> > Thanks.
> >
> > So for the code:
> >
> --
> >for (i = 0; i < CPU_COUNT; ++i) {
> >  const Per_CPU_Control *c;
> >  const Thread_Control *h;
> >
> >  c = _Per_CPU_Get_by_index(CPU_COUNT - 1 - i);
> >  h = c->heir;
> >
> >  sc = rtems_task_suspend(h->Object.id);
> >  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> >}
> >
> --
> >   would it have the same effect if we replace all this by :
> >
> >for (i = CPU_COUNT -1 ; i >=0 ; --i) {
> >  sc = rtems_task_suspend(ctx->task_ids[i]);
> >  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> >}
> >
> --
> >
> > Please let me know.
>
> No, it would not have the same effect in general. You can try to change
> it and see if the test fails or not.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: OFW Import To RTEMS License Issue

[Joel Sherrill]

On Tue, Aug 4, 2020 at 3:47 PM Gedare Bloom  wrote:

> On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer 
> wrote:
> >
> > I think for this one we can only hope that the original author agrees to
> > a re-licensing. Otherwise it is only possible to add a replacement.
> >
>
> I suggest starting to make a plan for a clean room re-implementation.
> Ideally, one entity can extract the requirements from the current code
> or interface and write them up, so that another entity can
> re-implement the code from the written requirements. This is a little
> bit challenging in our situation, since the only entities that will
> write the code have already been exposed to the copyrighted version.
> (https://en.wikipedia.org/wiki/Clean_room_design) But we can still try
> our best!
>

+1

IANAL but I don't expect hostility for having an independent implementation
of this interface anyway. This is likely just a case where the original
author
has been unresponsive to the NetBSD Foundation and me.

>
> Interfaces are not, in general, copyright-protected. So, the person
> that captures the requirements can rely on the interface, but needs to
> write the requirements for implementing the interface in their own
> words.
>

Yep.

>
> Gedare
>
> > On 04/08/2020 20:34, Niteesh G. S. wrote:
> > > ping.
> > >
> > >
> > > On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S.  > > > wrote:
> > >
> > >
> > >
> > > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill  > > > wrote:
> > >
> > >
> > >
> > > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.
> > > mailto:niteesh...@gmail.com>> wrote:
> > >
> > > Hello,
> > >
> > > In a recent review of these patches
> > >
> https://lists.rtems.org/pipermail/devel/2020-July/060653.html
> > > Gedare mentioned that we cannot use these patches with the
> > > current license. More details regarding the conversation
> can be
> > > found in the following archive.
> > >
> https://lists.rtems.org/pipermail/devel/2020-July/061000.html
> > >
> > > The following files have been ported to RTEMS to implement
> > > the OFW API.
> > > 1) openfirm.h  -- BSD-4 License
> > > 2) openfirm.c  -- BSD-4 License
> > > 3) ofw_fdt.c-- BSD-2 License
> > >
> > > The files with BSD4 cannot be used and Gedare suggested to
> > > check if we can remove the entire 4-clause cluster or
> remove
> > > clauses #3 and #4. I checked this along with the help of
> > > Christian
> > > and it seems that we can't remove those. Christian
> suggested
> > > that we can use the header file with the BSD-4 license to
> some
> > > extent but the source files to pose a problem. We also
> checked
> > > OpenBSD it has the same licensing.
> > >
> > >
> > > NetBSD appears to be the origin of the code and although I
> believe
> > > they did a largely blanket change from BSD-4, this code is old
> and
> > > normally, I would doubt they found the original submitter.
> Which
> > > would be odd in this case because this is his website with
> email:
> > >
> > > https://solfrank.net/Wolfgang/
> > >
> > > I have privately emailed to politely ask him to relicense it to
> > > BSD-2
> > > for use in RTEMS. And try to do that in a way that gets it on a
> > > path
> > > to get changed upstream.
> > >
> > > Hopefully this will solve it.
> > >
> > >
> > > Thanks for doing this Joel :).
> > >
> > >
> > >
> > > So we have come up with the following suggestions
> > > 1) Use the header files as it is.
> > >
> > >
> > > How close are you to being able to merge? Do we have time to
> let
> > > him answer?
> > >
> > >
> > > Yes, we do have a lot of time. All of my patches are based on the
> > > new build
> > > system so we won't be able to merge until the build system is
> > > merged. And
> > > also there are other things that have to be discussed regarding the
> > > patch.
> > >
> > >
> > >
> > > 2) Most OF_* functions defined in openfirm.c have 1:1
> mapping
> > > with the FDT implementation in ofw_fdt.c so there is a
> > > possibility
> > > to remove openfirm.c and only use openfirm.h and ofw_fdt.c.
> > > For those functions which don't have a 1:1 mapping, we can
> add
> > > an implementation in ofw_fdt.c. And remove the functions
> which
> > > don't have an FDT based implementation eg. OF_write,
> OF_open
> > > etc.
> > >
> > > Also please remember that these patches were created with
> a goal
> > > to import the OFW into RTEMS and remove them from libBSD so
> > > will using the above approach has a chance of bre

Re: [PATCH] fix Wunused-function deleting unused static functions in dl_tests

[Gedare Bloom]

On Wed, Aug 5, 2020 at 5:52 AM Aschref Ben-Thabet
 wrote:
>
> From: Aschref Ben Thabet 
>
> the functions dl_close and  dl_call are not needed for this test,
> deleting them will avoid the warning of Wunused-function.
> ---
>  testsuites/libtests/dl10/dl-load.c | 21 -
>  1 file changed, 21 deletions(-)
>
> diff --git a/testsuites/libtests/dl10/dl-load.c 
> b/testsuites/libtests/dl10/dl-load.c
> index dee1d6e9cc..a9d60a7e5a 100644
> --- a/testsuites/libtests/dl10/dl-load.c
> +++ b/testsuites/libtests/dl10/dl-load.c
> @@ -96,27 +96,6 @@ static void* dl_load_obj(const char* name, bool 
> has_unresolved)
>return handle;
>  }
>
> -static void dl_close (void* handle)
> -{
> -  int r;
> -  printf ("handle: %p closing\n", handle);
> -  r = dlclose (handle);
> -  if (r != 0)
> -printf("dlclose failed: %s\n", dlerror());
> -  rtems_test_assert (r == 0);
> -}
> -
> -static int dl_call (void* handle, const char* func)
> -{
> -  call_sig call = dlsym (handle, func);
> -  if (call == NULL)
> -  {
> -printf("dlsym failed: symbol not found: %s\n", func);
> -return 1;
> -  }
> -  call ();
> -  return 0;
> -}
>

This looks like it will leave 2 blank lines in a row, after deletion.
Delete one of the blank lines also. send revision with -v2.

>  int dl_load_test(void)
>  {
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: busdma: question about header

[Gabriel.Moyano]

Thank you very much Sebastian!

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Mittwoch, 5. August 2020 15:07
To: Moyano Heredia, Victor Gabriel; devel@rtems.org
Subject: Re: busdma: question about header

Hello Gabriel,

this should be fixed now.

-- 
Sebastian Huber, embedded brains GmbH
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] eng: Add application config options how-to

[Sebastian Huber]

Update #3715.
---
 eng/req/howto.rst | 118 ++
 1 file changed, 118 insertions(+)

diff --git a/eng/req/howto.rst b/eng/req/howto.rst
index 9a28427..475794c 100644
--- a/eng/req/howto.rst
+++ b/eng/req/howto.rst
@@ -34,6 +34,124 @@ environment in your shell:
 cd rtems-qual
 . env/bin/activate
 
+Application Configuration Options
+-
+
+The application configuration options and groups are maintained by
+specification items in the directory :file:`spec/if/acfg`.  Application
+configuration options are grouped by
+:ref:`SpecTypeApplicationConfigurationGroupItemType` items which should be
+stored in files using the :file:`spec/if/acfg/group-*.yml` pattern.  Each
+application configuration options shall link to exactly one group item with the
+:ref:`SpecTypeApplicationConfigurationGroupMemberLinkRole`.  There are four
+application option item types available which cover all existing options:
+
+* The *feature enable options* enable feature.  If the option is not defined by
+  the application configuration, then the feature is simply not available or
+  active.  There should be no feature-specific code linked to the application
+  if the option is not defined.  Examples are options which enable a device
+  driver like ``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER``.  These options are
+  specified by
+  :ref:`SpecTypeApplicationConfigurationFeatureEnableOptionItemType` items.
+
+* The *feature options* enable a feature if the option is defined by the
+  application configuration, otherwise another feature is active.  If the
+  option is not defined, then feature-specific code may linked to the
+  application.  Examples are options which disable a feature if the option is
+  defined such as ``CONFIGURE_APPLICATION_DISABLE_FILESYSTEM`` and options
+  which provide a stub implementation of a feature by default and a full
+  implementation if the option is defined such as
+  ``CONFIGURE_IMFS_ENABLE_MKFIFO``.  These options are specified by
+  :ref:`SpecTypeApplicationConfigurationFeatureOptionItemType` items.
+
+* The *integer value options* let the application define a specific value for a
+  system parameter.  If the option is not defined, then a default value is used
+  for the system parameter.  Examples are options which define the maximum
+  count of objects available for application use such as
+  ``CONFIGURE_MAXIMUM_TASKS``.  These options are specified by
+  :ref:`SpecTypeApplicationConfigurationValueOptionItemType` items.
+
+* The *initializer options* let the application define a specific initializer
+  for a system parameter.  If the option is not defined, then a default setting
+  is used for the system parameter.  An example option of this type is
+  ``CONFIGURE_INITIAL_EXTENSIONS``.  These options are specified by
+  :ref:`SpecTypeApplicationConfigurationValueOptionItemType` items.
+
+From the specification items Sphinx documentation sources and header files with
+Doxygen markup are generated.  The descriptions in the items shall use a
+restricted Sphinx formatting.  Emphasis via one asterix ("*"), strong emphasis
+via two asterix ("**"), code samples via blockquotes ("``"), code blocks ("..
+code-block:: c") and lists are allowed.  References to interface items are also
+allowed, for example "${appl-needs-clock-driver:/name}" and
+"${../rtems/tasks/create:/name}".  References to other parts of the
+documentation are possible, however, they are currently provided by hard-coded
+tables in :file:`rtemsspec/applconfig.py`.
+
+Modify an Existing Group
+
+
+Search for the group by its section header and edit the specification item
+file.  For example:
+
+.. code-block:: none
+
+$ grep -rl "name: General System Configuration" spec/if/acfg
+spec/if/acfg/group-general.yml
+$ vi spec/if/acfg/group-general.yml
+
+Modify an Existing Option
+^
+
+Search for the option by its define name and edit the specification item file.
+For example:
+
+.. code-block:: none
+
+$ grep -rl CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER spec/if/acfg
+spec/if/acfg/appl-needs-clock-driver.yml
+$ vi spec/if/acfg/appl-needs-clock-driver.yml
+
+Add a New Group
+^^^
+
+Let ``new`` be the UID name part of the new group.  Create the file
+:file:`spec/if/acfg/group-new.yml` and provide all attributes for an
+:ref:`SpecTypeApplicationConfigurationGroupItemType` item.  For example:
+
+.. code-block:: none
+
+$ vi spec/if/acfg/group-new.yml
+
+Add a New Option
+
+
+Let ``my-new-option`` be the UID name of the option.  Create the file
+:file:`if/acfg/my-new-option.yml` and provide all attributes for an appropriate
+refinement of :ref:`SpecTypeApplicationConfigurationOptionItemType`.  For
+example:
+
+.. code-block:: none
+
+$ vi spec/if/acfg/my-new-option.yml
+
+Generate Content after Changes
+^^
+
+Once you are done with the modificati

[PATCH 2/2] c-user: Avoid Sphinx-specifics in appl config

[Sebastian Huber]

This helps to generate Doxygen markup from the application configuration
option specification items.

Update #3994.
---
 c-user/config/bsp-related.rst   |  8 ++--
 c-user/config/classic-api.rst   | 63 -
 c-user/config/classic-init-task.rst |  2 +-
 c-user/config/device-driver.rst | 26 ++--
 c-user/config/filesystem.rst| 28 ++---
 c-user/config/general.rst   | 12 +++---
 c-user/config/mpci.rst  |  2 +-
 c-user/config/posix-api.rst | 52 +---
 c-user/config/scheduler-general.rst |  6 +--
 9 files changed, 107 insertions(+), 92 deletions(-)

diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
index 5af5cc2..0b3436c 100644
--- a/c-user/config/bsp-related.rst
+++ b/c-user/config/bsp-related.rst
@@ -104,7 +104,7 @@ DEFAULT VALUE:
 
 VALUE CONSTRAINTS:
 The value of this configuration option shall be a list of initializers for
-structures of type :c:type:`rtems_extensions_table`.
+structures of type ``rtems_extensions_table``.
 
 DESCRIPTION:
 If
@@ -181,7 +181,7 @@ DEFAULT VALUE:
 
 VALUE CONSTRAINTS:
 The value of this configuration option shall be a list of initializers for
-structures of type :c:type:`rtems_extensions_table`.
+structures of type ``rtems_extensions_table``.
 
 DESCRIPTION:
 If
@@ -259,9 +259,9 @@ DESCRIPTION:
 * and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
 
 then not all memory is made available to the C Program Heap immediately at
-system initialization time.  When :c:func:`malloc()` or other standard 
memory
+system initialization time.  When ``malloc()`` or other standard memory
 allocation functions are unable to allocate memory, they will call the BSP
-supplied :c:func:`sbrk()` function to obtain more memory.
+supplied ``sbrk()`` function to obtain more memory.
 
 NOTES:
 This option should not be defined by the application. Only the BSP knows 
how
diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst
index 41994e0..07c79b2 100644
--- a/c-user/config/classic-api.rst
+++ b/c-user/config/classic-api.rst
@@ -37,9 +37,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -78,9 +79,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -121,9 +123,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -162,9 +165,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :c:func:`rtems_resource_unlimited` the enable unlimited objects for this
-  object class, if the value passed to :c:func:`rtems_resource_unlimited`
-  satisfies all other constraints of this configuration option.
+  ``rtems_resource_unlimited()`` the enable unlimited objects for
+  this object class, if the value passed to
+  ``rtems_resource_unlimited()`` satisfies all other constraints
+  of this configuration option.
 
 DESCRIPTION:
 The value of this configuration option defines the maximum number of 
Classic
@@ -203,9 +207,10 @@ VALUE CONSTRAINTS:
   memory available to the application.
 
 * It may be defined through
-  :

Re: [PATCH 2/2] c-user: Avoid Sphinx-specifics in appl config

[Sebastian Huber]

On 06/08/2020 07:46, Sebastian Huber wrote:


This helps to generate Doxygen markup from the application configuration
option specification items.

Update #3994.
Please ignore the second patch. I will use another approach do address 
this issue.

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