On 26/11/20 4:08 am, Gedare Bloom wrote: > > > On Wed, Nov 25, 2020 at 7:38 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto: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
And me Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
