Requirements depending on application configuration should use the described approach.
Update #3715. --- eng/req/howto.rst | 67 +++++++++++++++++------------------------------ 1 file changed, 24 insertions(+), 43 deletions(-) diff --git a/eng/req/howto.rst b/eng/req/howto.rst index ea4a57d..ad2b962 100644 --- a/eng/req/howto.rst +++ b/eng/req/howto.rst @@ -440,61 +440,42 @@ of :c:func:`rtems_signal_catch`: Requirements Depending on Application Configuration Options ----------------------------------------------------------- -Requirements which depend on application configuration options such as +Requirements depending on application configuration options such as :c:data:`CONFIGURE_MAXIMUM_PROCESSORS` should be written in the following :ref:`syntax <ReqEngSyntax>`: **Where** <feature is included>, the <system name> shall <system response>. -Use these clauses with care. Make sure all feature combinations are covered. -Using a truth table may help. If a requirement depends on multiple features, -use: - - **Where** <feature 0>, **where** <feature 1>, **where** <feature ...>, the - <system name> shall <system response>. - -For application configuration options, use the clauses like this: - -:c:data:`CONFIGURE_MAXIMUM_PROCESSORS` equal to one - - **Where** the system was configured with a processor maximum of exactly - one, ... - -:c:data:`CONFIGURE_MAXIMUM_PROCESSORS` greater than one - - **Where** the system was configured with a processor maximum greater than - one, ... - -Please have a look at the following example used to specify -:c:func:`rtems_signal_catch`. The example is a post-condition state -specification of an action requirement, so there is an implicit set of -pre-conditions and the trigger: - - **While** <pre-condition(s)>, **when** rtems_signal_catch() is called, ... - -The *where* clauses should be mentally placed before the *while* clauses. +For action requirements, the **where** clauses should be added to the head of +pre-conditions list. Please have a look at the following example used to +specify :c:func:`rtems_task_construct`. The example is a pre-condition state +specification of an action requirement: .. code-block:: yaml - post-conditions: - - name: ASRInfo + pre-conditions: + - name: CPUs states: - - name: NopNoPreempt + - name: One test-code: | - if ( rtems_configuration_get_maximum_processors() > 1 ) { - CheckNoASRChange( ctx ); - } else { - CheckNewASRSettings( ctx ); + if ( rtems_scheduler_get_processor_maximum() != 1 ) { + ${.:skip} } text: | - Where the scheduler does not support the no-preempt mode, the ASR - information of the caller of ${../if/catch:/name} shall not be - changed by the ${../if/catch:/name} call. - - Where the scheduler does support the no-preempt mode, the ASR - processing for the caller of ${../if/catch:/name} shall be done using - the handler specified by ${../if/catch:/params[0]/name} in the mode - specified by ${../if/catch:/params[1]/name}. + Where the system does not need inter-processor interrupts, + where the scheduler does support the no-preempt mode. + - name: More + test-code: | + if ( rtems_scheduler_get_processor_maximum() == 1 ) { + ${.:skip} + } + text: | + Where the system needs inter-processor interrupts, + where the scheduler does not support the no-preempt mode. + +The test case needs to run in all required configurations. This requires that +the test case is added to multiple test suites. Use the ``${.:skip}`` +substitution to skip conditions not supported by the current configuration. Action Requirements ------------------- -- 2.35.3 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel