Re: [PATCH] eng: Add performance specification items
Hello,
On 14/11/2020 12:59, Sebastian Huber wrote:
On 13/11/2020 20:03, Gedare Bloom wrote:
+Generic Non-Functional Requirement Item Type
+
+
+This type refines the following types:
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
through?
Nice an automatically generated typo.
+ ``non-functional-type`` attribute if the value is
``build-configuration``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``constraint``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``design``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``documentation``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``interface``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is
``interface-requirement``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is
``maintainability``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``performance``
+
Is there a specific kind of performance (metric) in mind? latency vs
throughput? Or does it not matter
In the generic non-functional requirements, the requirements text is
in natural language. So, you can write whatever you want.
This patch introduces a specialization for performance requirements
which are expressed in limits of a sample set of some measured runtime
of an operation.
text: |
When a partition has exactly
${../val/performance:/params/buffer-count} free
buffers, the ${.:limit-kind} runtime of exactly
${../val/performance:/params/sample-count} successful calls to
${../if/get-buffer:/name} in the ${.:/environment} shall be
${.:limit-condition}.
In this item, the corresponding test code is also included.
test-body:
brief: |
Get a buffer.
code: |
ctx->status = rtems_partition_get_buffer( ctx->part_many,
&ctx->buffer );
description: null
I think this can be checked in independent of the open discussion how a
particular performance limit is identified. The item just uses a string
to identify a set of performance limits. An open issue is how this
string is generated and what data it includes.
I already fixed the "though" -> "through" typo.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] tester: Report fatal-error test states as failures
Tests resulting in the fatal-error state are counted as failures, but are not currently reported in the text summary. This has already been fixed for JSON output. --- tester/rt/report.py | 1 + 1 file changed, 1 insertion(+) diff --git a/tester/rt/report.py b/tester/rt/report.py index be8df74..0e19edc 100644 --- a/tester/rt/report.py +++ b/tester/rt/report.py @@ -321,6 +321,7 @@ class report(object): if self.failed: l += ['Failures:'] l += show_state(self.results, 'failed', self.name_max_len) +l += show_state(self.results, 'fatal-error', self.name_max_len) if self.user_input: l += ['User Input:'] l += show_state(self.results, 'user-input', self.name_max_len) -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] eng: Add performance specification items
On Wed, Nov 25, 2020 at 7:38 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> On 14/11/2020 12:59, Sebastian Huber wrote:
> > On 13/11/2020 20:03, Gedare Bloom wrote:
> >
> >>> +Generic Non-Functional Requirement Item Type
> >>> +
> >>> +
> >>> +This type refines the following types:
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >> through?
> > Nice an automatically generated typo.
> >>
> >>> + ``non-functional-type`` attribute if the value is
> >>> ``build-configuration``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is ``constraint``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is ``design``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is ``documentation``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is ``interface``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is
> >>> ``interface-requirement``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is
> >>> ``maintainability``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> + ``non-functional-type`` attribute if the value is ``performance``
> >>> +
> >> Is there a specific kind of performance (metric) in mind? latency vs
> >> throughput? Or does it not matter
> >>
> > In the generic non-functional requirements, the requirements text is
> > in natural language. So, you can write whatever you want.
> >
> > This patch introduces a specialization for performance requirements
> > which are expressed in limits of a sample set of some measured runtime
> > of an operation.
> >
> > text: |
> > When a partition has exactly
> > ${../val/performance:/params/buffer-count} free
> > buffers, the ${.:limit-kind} runtime of exactly
> > ${../val/performance:/params/sample-count} successful calls to
> > ${../if/get-buffer:/name} in the ${.:/environment} shall be
> > ${.:limit-condition}.
> >
> > In this item, the corresponding test code is also included.
> >
> > test-body:
> > brief: |
> > Get a buffer.
> > code: |
> > ctx->status = rtems_partition_get_buffer( ctx->part_many,
> > &ctx->buffer );
> > description: null
>
> I think this can be checked in independent of the open discussion how a
> particular performance limit is identified. The item just uses a string
> to identify a set of performance limits. An open issue is how this
> string is generated and what data it includes.
>
> I already fixed the "though" -> "through" typo.
>
> Fine with me
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hub...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3] c-user: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE
On Wed, Nov 25, 2020 at 12:14 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Document new configuration option > CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE. > > Close #4181. > --- > c-user/config/classic-init-task.rst | 67 - > 1 file changed, 66 insertions(+), 1 deletion(-) > > diff --git a/c-user/config/classic-init-task.rst > b/c-user/config/classic-init-task.rst > index 4d3bf81..d848546 100644 > --- a/c-user/config/classic-init-task.rst > +++ b/c-user/config/classic-init-task.rst > @@ -79,6 +79,65 @@ DESCRIPTION: > NOTES: > None. > > +.. Generated from spec:/acfg/if/init-task-construct-storage-size > + > +.. index:: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE > + > +.. _CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE: > + > +CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE > +-- > + > +CONSTANT: > +``CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE`` > + > +OPTION TYPE: > +This configuration option is an integer define. > + > +DEFAULT VALUE: > +The default value is 0. > + > +VALUE CONSTRAINTS: > +The value of this configuration option shall satisfy all of the > following > +constraints: > + > +* It shall be greater than or equal to > :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE`. > + > I guess the constraints don't apply to defaults? Or should an exception be noted, like below .. "if specified" > +* It shall be defined using > + :c:func:`RTEMS_TASK_STORAGE_SIZE`. > + > +DESCRIPTION: > +The value of this configuration option defines the task storage size > of the > +Classic API initialization task. > + > +NOTES: > +If this configuration option is specified, then > + > +* a task storage area of the specified size is statically allocated by > + for the Classic API initialization task, > + > +* the Classic API initialization task is constructed by > + :c:func:`rtems_task_construct` instead of using > + :c:func:`rtems_task_create`, > + > +* the maximum thread-local storage size defined by > + :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE` is used for the > Classic API > + initialization task, > + > +* the Classic API initialization task should be accounted for in > + :ref:`CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE`, and > + > +* the task storage area used for the Classic API initialization task > is not > + reclaimed by the system, if the task is deleted. > nit: remove comma > + > +The > + > +* :ref:`CONFIGURE_INIT_TASK_STACK_SIZE` and > + > +* ``CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE`` > + > +configuration options are mutually exclusive. > + > .. Generated from spec:/acfg/if/init-task-entrypoint > > .. index:: CONFIGURE_INIT_TASK_ENTRY_POINT > @@ -229,7 +288,13 @@ DESCRIPTION: > Classic API initialization task. > > NOTES: > -None. > +The > + > +* ``CONFIGURE_INIT_TASK_STACK_SIZE`` and > + > +* :ref:`CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE` > + > +configuration options are mutually exclusive. > > .. Generated from spec:/acfg/if/rtems-init-tasks-table > > -- > 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 2/4] score: Return a status in _Objects_Set_name()
Should rtems_object_set_name() propagate the memory error condition also?
On Tue, Nov 24, 2020 at 5:52 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> ---
> cpukit/include/rtems/score/objectimpl.h | 14 --
> cpukit/score/src/objectsetname.c| 6 +++---
> testsuites/psxtests/psxobj01/init.c | 6 +++---
> 3 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/objectimpl.h
> b/cpukit/include/rtems/score/objectimpl.h
> index 32387594f2..a963396d65 100644
> --- a/cpukit/include/rtems/score/objectimpl.h
> +++ b/cpukit/include/rtems/score/objectimpl.h
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -463,14 +464,15 @@ size_t _Objects_Name_to_string(
> * or up to the first four characters of the string based upon
> * whether this object class uses strings for names.
> *
> - * @param information points to the object information structure
> - * @param[out] the_object is the object to operate upon
> - * @param name is a pointer to the name to use
> + * @param information points to the object information.
> + * @param[out] the_object is the object to operate upon.
> + * @param name is a pointer to the name to use.
> *
> - * @retval true The operation succeeded.
> - * @retval false The operation failed.
> + * @retval STATUS_SUCCESSFUL The operation succeeded.
> + *
> + * @retval STATUS_NO_MEMORY There was no memory available to duplicate
> the name.
> */
> -bool _Objects_Set_name(
> +Status_Control _Objects_Set_name(
>const Objects_Information *information,
>Objects_Control *the_object,
>const char*name
> diff --git a/cpukit/score/src/objectsetname.c
> b/cpukit/score/src/objectsetname.c
> index 0808ab87af..4d85332711 100644
> --- a/cpukit/score/src/objectsetname.c
> +++ b/cpukit/score/src/objectsetname.c
> @@ -24,7 +24,7 @@
>
> #include
>
> -bool _Objects_Set_name(
> +Status_Control _Objects_Set_name(
>const Objects_Information *information,
>Objects_Control *the_object,
>const char*name
> @@ -37,7 +37,7 @@ bool _Objects_Set_name(
> length = strnlen( name, information->name_length );
> dup = _Workspace_String_duplicate( name, length );
> if ( dup == NULL ) {
> - return false;
> + return STATUS_NO_MEMORY;
> }
>
> the_object->name.name_p = dup;
> @@ -59,5 +59,5 @@ bool _Objects_Set_name(
>_Objects_Build_name( c[ 0 ], c[ 1 ], c[ 2 ], c[ 3 ] );
>}
>
> - return true;
> + return STATUS_SUCCESSFUL;
> }
> diff --git a/testsuites/psxtests/psxobj01/init.c
> b/testsuites/psxtests/psxobj01/init.c
> index ba1e327ea5..fef749b3e9 100644
> --- a/testsuites/psxtests/psxobj01/init.c
> +++ b/testsuites/psxtests/psxobj01/init.c
> @@ -37,7 +37,7 @@ static rtems_task Init(
>Objects_Control *the_object;
>char name[64];
>size_t name_len;
> - bool bc;
> + Status_Control status;
>
>TEST_BEGIN();
>
> @@ -70,12 +70,12 @@ static rtems_task Init(
>puts( "INIT - _Objects_Set_name fails - out of memory" );
>rtems_workspace_greedy_allocate( NULL, 0 );
>
> - bc = _Objects_Set_name(
> + status = _Objects_Set_name(
> &Test_Information,
> &_Thread_Get_executing()->Object,
> name
>);
> - rtems_test_assert( bc == false );
> + rtems_test_assert( status == STATUS_NO_MEMORY );
>
>TEST_END();
>rtems_test_exit(0);
> --
> 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 3/4] rtems: Fix rtems_object_set_name()
nvm... On Tue, Nov 24, 2020 at 5:52 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Return RTEMS_NO_MEMORY if there is not memory available to duplicate the > name. > --- > cpukit/rtems/src/rtemsobjectsetname.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/cpukit/rtems/src/rtemsobjectsetname.c > b/cpukit/rtems/src/rtemsobjectsetname.c > index 9e1b3a4039..ca663c67cd 100644 > --- a/cpukit/rtems/src/rtemsobjectsetname.c > +++ b/cpukit/rtems/src/rtemsobjectsetname.c > @@ -36,6 +36,7 @@ rtems_status_code rtems_object_set_name( >Objects_Information *information; >Objects_Control *the_object; >Objects_Id tmpId; > + Status_Control status; > >if ( !name ) > return RTEMS_INVALID_ADDRESS; > @@ -54,7 +55,7 @@ rtems_status_code rtems_object_set_name( > return RTEMS_INVALID_ID; >} > > - _Objects_Set_name( information, the_object, name ); > + status = _Objects_Set_name( information, the_object, name ); >_Objects_Allocator_unlock(); > - return RTEMS_SUCCESSFUL; > + return STATUS_GET_CLASSIC( status ); > } > -- > 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 4/4] score: Free old name in _Objects_Set_name()
These 4 patches look good to me
On Tue, Nov 24, 2020 at 5:52 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> This is the behaviour document in the RTEMS Classic API Guide.
> ---
> cpukit/score/src/objectsetname.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/cpukit/score/src/objectsetname.c
> b/cpukit/score/src/objectsetname.c
> index 4d85332711..4cb19bd360 100644
> --- a/cpukit/score/src/objectsetname.c
> +++ b/cpukit/score/src/objectsetname.c
> @@ -40,6 +40,7 @@ Status_Control _Objects_Set_name(
>return STATUS_NO_MEMORY;
> }
>
> +_Workspace_Free( the_object->name.name_p );
> the_object->name.name_p = dup;
>} else {
> char c[ 4 ];
> --
> 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 v2] rtems: Delete rtems_object_id_api_maximum_class()
Analysis looks fine to me, Joel you alright with that? I assume the doc patch will come with generation of the api? On Tue, Nov 24, 2020 at 5:50 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > This directive has no implementation. It is documented in the RTEMS > Classic API Guide. > > It was added by > > commit 6c06288f6452da96fa630f1482aeaaba5d217531 > Author: Joel Sherrill > Date: Tue Jan 29 21:52:21 2008 + > > without an implementation. The later change > > commit fdc57ca4b6794dc17c7b7d94ae557da21e314d6a > Author: Joel Sherrill > Date: Mon Nov 23 14:53:04 2009 + > > renamed the similar rtems_object_id_api_maximum_class() in > rtems_object_api_minimum_class(). > > The rtems_object_api_maximum_class() is documented and implemented. It > can be assumed that the rtems_object_id_api_maximum_class() is a > fragement left over from development. > --- > cpukit/include/rtems/rtems/object.h | 17 - > 1 file changed, 17 deletions(-) > > diff --git a/cpukit/include/rtems/rtems/object.h > b/cpukit/include/rtems/rtems/object.h > index 8e8bfbf293..77c13f473f 100644 > --- a/cpukit/include/rtems/rtems/object.h > +++ b/cpukit/include/rtems/rtems/object.h > @@ -285,23 +285,6 @@ int rtems_object_api_maximum_class( >int api > ); > > - > -/** > - * @brief Get Highest Valid Class Value > - * > - * This method returns the lowest valid value Class for the > - * specified @a api. Each API supports a different number > - * of object classes. > - * > - * @param[in] api is the API to obtain the maximum class of > - * > - * @retval This method returns the least valid value for > - * class number for the specified @a api. > - */ > -int rtems_object_id_api_maximum_class( > - int api > -); > - > /** > * @brief Get API Name > * > -- > 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 v4] c-user: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE
Document new configuration option CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE. Close #4181. --- v4: * Clarify default value. * Remove comma. c-user/config/classic-init-task.rst | 69 - 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/c-user/config/classic-init-task.rst b/c-user/config/classic-init-task.rst index 4d3bf81..b331e40 100644 --- a/c-user/config/classic-init-task.rst +++ b/c-user/config/classic-init-task.rst @@ -79,6 +79,67 @@ DESCRIPTION: NOTES: None. +.. Generated from spec:/acfg/if/init-task-construct-storage-size + +.. index:: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE + +.. _CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE: + +CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE +-- + +CONSTANT: +``CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE`` + +OPTION TYPE: +This configuration option is an integer define. + +DEFAULT VALUE: +This configuration option has no default value. If it is not specified, then +the Classic API initialization task will be created with the stack size +defined by the :ref:`CONFIGURE_INIT_TASK_STACK_SIZE` configuration option. + +VALUE CONSTRAINTS: +The value of this configuration option shall satisfy all of the following +constraints: + +* It shall be greater than or equal to :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE`. + +* It shall be defined using + :c:func:`RTEMS_TASK_STORAGE_SIZE`. + +DESCRIPTION: +The value of this configuration option defines the task storage size of the +Classic API initialization task. + +NOTES: +If this configuration option is specified, then + +* a task storage area of the specified size is statically allocated by + for the Classic API initialization task, + +* the Classic API initialization task is constructed by + :c:func:`rtems_task_construct` instead of using + :c:func:`rtems_task_create`, + +* the maximum thread-local storage size defined by + :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE` is used for the Classic API + initialization task, + +* the Classic API initialization task should be accounted for in + :ref:`CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE`, and + +* the task storage area used for the Classic API initialization task is not + reclaimed by the system if the task is deleted. + +The + +* :ref:`CONFIGURE_INIT_TASK_STACK_SIZE` and + +* ``CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE`` + +configuration options are mutually exclusive. + .. Generated from spec:/acfg/if/init-task-entrypoint .. index:: CONFIGURE_INIT_TASK_ENTRY_POINT @@ -229,7 +290,13 @@ DESCRIPTION: Classic API initialization task. NOTES: -None. +The + +* ``CONFIGURE_INIT_TASK_STACK_SIZE`` and + +* :ref:`CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE` + +configuration options are mutually exclusive. .. Generated from spec:/acfg/if/rtems-init-tasks-table -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Generate Object Services documentation
The problem with reading my email top-to-bottom... Sometimes I miss context. (The problem of reading bottom-to-top, sometimes I miss context.) I see this patch fixes up the rtems_object_id_api_maximum. Since this API was never functional, I suppose it is acceptable to drop it directly. Does a note need to be added anywhere (obsolete API)? I lean toward no, because it is a vacuous proof problem. The API never existed outside of Joel's head ;) I usually like to see the generated documentation for review. On Tue, Nov 24, 2020 at 5:44 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > The documentation is a consolidation of the comments in Doxygen markup > and the documentation sources in Sphinx markup. The documentation was > transfered to interface specification items. This header file was > generated from the items by a script. > > Update #3993. > --- > c-user/object-services/directives.rst | 978 ++-- > c-user/object-services/introduction.rst | 93 ++- > 2 files changed, 643 insertions(+), 428 deletions(-) > > diff --git a/c-user/object-services/directives.rst > b/c-user/object-services/directives.rst > index 87f0f5a..c760559 100644 > --- a/c-user/object-services/directives.rst > +++ b/c-user/object-services/directives.rst > @@ -1,643 +1,805 @@ > .. SPDX-License-Identifier: CC-BY-SA-4.0 > > -.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation > (OAR) > +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de > ) > +.. Copyright (C) 1988, 2009 On-Line Applications Research Corporation > (OAR) > + > +.. This file is part of the RTEMS quality process and was automatically > +.. generated. If you find something that needs to be fixed or > +.. worded better please post a report or patch to an RTEMS mailing list > +.. or raise a bug report: > +.. > +.. https://docs.rtems.org/branches/master/user/support/bugs.html > +.. > +.. For information on updating and regenerating please refer to: > +.. > +.. https://docs.rtems.org/branches/master/eng/req/howto.html > + > +.. _ObjectServicesDirectives: > > Directives > == > > +This section details the directives of the Object Services. A subsection > is > +dedicated to each of this manager's directives and lists the calling > sequence, > +parameters, description, return values, and notes of the directive. > + > +.. Generated from spec:/rtems/object/if/build-id > + > .. raw:: latex > > - \clearpage > +\clearpage > + > +.. index:: rtems_build_id() > + > +.. _InterfaceRtemsBuildId: > + > +rtems_build_id() > + > + > +Builds the object identifier from the API, class, MPCI node, and index > +components. > + > +.. rubric:: CALLING SEQUENCE: > + > +.. code-block:: c > + > +#define rtems_build_id( _api, _class, _node, _index ) > > -.. index:: build object name > -.. index:: rtems_build_name > +.. rubric:: PARAMETERS: > > -.. _rtems_build_name: > +``_api`` > +This parameter is the API of the object identifier to build. > > -BUILD_NAME - Build object name from characters > --- > +``_class`` > +This parameter is the class of the object identifier to build. > > -CALLING SEQUENCE: > -.. code-block:: c > +``_node`` > +This parameter is the MPCI node of the object identifier to build. > > -rtems_name rtems_build_name( > -uint8_t c1, > -uint8_t c2, > -uint8_t c3, > -uint8_t c4 > -); > +``_index`` > +This parameter is the index of the object identifier to build. > > -DIRECTIVE STATUS CODES: > -Returns a name constructed from the four characters. > +.. rubric:: RETURN VALUES: > > -DESCRIPTION: > -This service takes the four characters provided as arguments and > constructs > -a thirty-two bit object name with ``c1`` in the most significant byte > and > -``c4`` in the least significant byte. > +Returns the object identifier built from the API, class, MPCI node, and > index > +components. > > -NOTES: > -This directive is strictly local and does not impact task scheduling. > +.. rubric:: NOTES: > + > +This directive is strictly local and does not impact task scheduling. > + > +.. Generated from spec:/rtems/object/if/build-name > > .. raw:: latex > > - \clearpage > +\clearpage > > -.. index:: get name from id > -.. index:: obtain name from id > -.. index:: rtems_object_get_classic_name > +.. index:: rtems_build_name() > > -.. _rtems_object_get_classic_name: > +.. _InterfaceRtemsBuildName: > > -OBJECT_GET_CLASSIC_NAME - Lookup name from id > -- > +rtems_build_name() > +-- > > -CALLING SEQUENCE: > -.. code-block:: c > +Builds the object name composed of the four characters. > > -rtems_status_code rtems_object_get_classic_name( > -rtems_id id, > -rtems_name *name > -); > +.. rubric:: CALLING SEQUENCE: > > -DIRECTIVE STAT
Re: [PATCH] c-user: Generate Object Services documentation
On 25/11/2020 18:45, Gedare Bloom wrote: I usually like to see the generated documentation for review. Sorry, I forgot to add a link: https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf I can't upload the Doxygen due to a full disk. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hub...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposal for hardware configuration dependent performance limits
On 23/11/20 8:14 pm, Sebastian Huber wrote: > On 22/11/2020 22:45, Chris Johns wrote: > >>> My point is that we need a key reported by the BSP and then some >>> performance >>> limits which can be found by arch/bsp/key to check if there are >>> performance >>> regressions. >> I am missing the place where the performance limits are held. Do the >> tests >> report timing values and the checks against the limits happen on a host? > Yes, this is what I proposed. Thanks and sorry for not picking up on this before now. It makes sense to do it this way. >>> I chimed in on the idea of not using a hash, because of the opaqueness >>> of the specification and difficulty to derive what should be >>> reasonable performance based on small configuration changes from a >>> standard set. In that case, we do punt some responsibility to the end >>> user to start from a configuration with a known hash and performance >>> bounds before defining their own. Otherwise, the best they can do is >>> like what we do: run it, record the measurements, and use those as the >>> bounds moving forward. >>> >>> When a user sends us a report saying my configuration >>> a/lwjeVQ:H#TIHFOAH doesn't match the performance of >>> z./hleg.khEHWIWEHFWHFE then we can have this conversation again. :) >> If the user is basing their figures on a set of results we publish would >> providing a description in the YAML be sufficient? This moves the burden of >> maintenance from being internal to RTEMS to outside. And I am fine if there >> are >> mandatory informational fields. > > In the proposal the performance limits are optional in the specification. The > specifications only enables you to check limits in test runs. We should > probably > not integrate limits for custom hardware in the RTEMS Project. We could add > performance limits for some evaluation boards or simulators which we use for > regular test runs to notice performance regressions. The configuration hashes > included in the RTEMS Project need to be documented (in the BSP build item) to > have a reverse mapping, e.g. XrY7u+Ae7tCTyyK7j1rNww== is board X revision Y > running at 123MHz with SMP enabled, etc. Users which want to monitor > performance > requirements have to use also this approach: > > 1. You select a board to use for long term performance tests. > > 2. You define a set of configurations you want to test. > > 3. You do an initial run of the test suite for each configuration. The RTEMS > Tester provides you with a machine readable output (test data) of the test run > with the raw test output per test executable and some meta information (TODO). > > 4. A tool reads the test data and the RTEMS specification and updates the > specification with the performance limits obtained from the test run (maybe > with > some simple transformation, for example increase maximum by 10% and round to > microseconds). > > 5. You review the performance limits and then commit them to your private > branch. > > 6. Later you run the tests with a new RTEMS commit, get the performance > values, > compare them against the limits stored in the specification, and generate a > report. > > Maybe a configuration option for the RTEMS Tester should be added which allows > you to set the performance hash and ignore the hash provided by the test > output. > This could be used to compare a custom board with values obtain from an > evaluation board. Why not let the tester take an alternative set of values for the same hash to override the "standard" set? Chris ps: sorry I forgot to send this. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: waf examples: how to modify linker flags/how to process generated exe.
On 24/11/20 6:03 pm, Sebastian Huber wrote: > a post-link step (for example a transformation of the ELF file into a boot > loader image) is currently not supported by the new build system. For this the > idea is to let the BSP optionally provide a "post-link" command line tool (a > shell script for example) Adding to what Sebastian has said, this script will be installed with the BSP and the script name will be the same for all BSPs. The idea is to create a command line interface that will let you do a standard set of post-link functions in a consistent manner across all BSPs. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tester: Report fatal-error test states as failures
On 26/11/20 1:55 am, Kinsey Moore wrote: > Tests resulting in the fatal-error state are counted as failures, but > are not currently reported in the text summary. This has already been > fixed for JSON output. OK to push. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] rtems: Remove unused barriermp.h
---
cpukit/rtems/include/rtems/rtems/barriermp.h | 127 ---
1 file changed, 127 deletions(-)
delete mode 100644 cpukit/rtems/include/rtems/rtems/barriermp.h
diff --git a/cpukit/rtems/include/rtems/rtems/barriermp.h
b/cpukit/rtems/include/rtems/rtems/barriermp.h
deleted file mode 100644
index d215ecdb5f..00
--- a/cpukit/rtems/include/rtems/rtems/barriermp.h
+++ /dev/null
@@ -1,127 +0,0 @@
-/**
- * @file
- *
- * @brief MP Support in the Barrier Manager
- *
- * This include file contains all the constants and structures associated
- * with the Multiprocessing Support in the Barrier Manager.
- */
-
-/* COPYRIGHT (c) 1989-2013.
- * On-Line Applications Research Corporation (OAR).
- *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#ifndef _RTEMS_RTEMS_BARRIERMP_H
-#define _RTEMS_RTEMS_BARRIERMP_H
-
-#include
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/**
- * @defgroup ClassicBarrierMP Barrier MP Support
- *
- * @ingroup ClassicMP
- *
- * This encapsulates functionality related to the transparent multiprocessing
- * support within the Classic API Barrier Manager.
- */
-/**@{*/
-
-/**
- * The following enumerated type defines the list of
- * remote barrier operations.
- */
-typedef enum {
- BARRIER_MP_ANNOUNCE_CREATE = 0,
- BARRIER_MP_ANNOUNCE_DELETE = 1,
- BARRIER_MP_EXTRACT_PROXY= 2,
- BARRIER_MP_WAIT_REQUEST = 3,
- BARRIER_MP_WAIT_RESPONSE= 4,
- BARRIER_MP_RELEASE_REQUEST = 5,
- BARRIER_MP_RELEASE_RESPONSE = 6
-} Barrier_MP_Remote_operations;
-
-/**
- * The following data structure defines the packet used to perform
- * remote barrier operations.
- */
-typedef struct {
- rtems_packet_prefix Prefix;
- Barrier_MP_Remote_operations operation;
- rtems_namename;
- rtems_option option_set;
- Objects_Idproxy_id;
-} Barrier_MP_Packet;
-
-/**
- * @brief _Barrier_MP_Send_process_packet
- *
- * This routine performs a remote procedure call so that a
- * process operation can be performed on another node.
- */
-void _Barrier_MP_Send_process_packet (
- Barrier_MP_Remote_operations operation,
- Objects_Id barrier_id,
- rtems_name name,
- Objects_Id proxy_id
-);
-
-/**
- * @brief _Barrier_MP_Send_request_packet
- *
- * This routine performs a remote procedure call so that a
- * directive operation can be initiated on another node.
- */
-rtems_status_code _Barrier_MP_Send_request_packet (
- Barrier_MP_Remote_operations operation,
- Objects_Id barrier_id,
- rtems_interval timeout
-);
-
-/**
- * @brief _Barrier_MP_Process_packet
- *
- * This routine performs the actions specific to this package for
- * the request from another node.
- */
-void _Barrier_MP_Process_packet (
- rtems_packet_prefix *the_packet_prefix
-);
-
-/**
- * @brief _Barrier_MP_Send_object_was_deleted
- *
- * This routine is invoked indirectly by the thread queue
- * when a proxy has been removed from the thread queue and
- * the remote node must be informed of this.
- */
-void _Barrier_MP_Send_object_was_deleted (
- Thread_Control *the_proxy
-);
-
-/**
- * @brief _Barrier_MP_Send_extract_proxy
- *
- * This routine is invoked when a task is deleted and it
- * has a proxy which must be removed from a thread queue and
- * the remote node must be informed of this.
- */
-void _Barrier_MP_Send_extract_proxy (
- void *argument
-);
-
-/**@}*/
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif
-/* end of file */
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
