Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?
Hello， I have a TI bsp which uses a ARM cortex A72 process. It has 4 cores and MMU enabled. So does rtems support SMP and MMU in such a platform? After searching the mail and source code, I only find a cortex A53 platform. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/33] Test framework improvements
On 23/07/2020 00:25, Chris Johns wrote: On 22/7/20 7:16 pm, Sebastian Huber wrote: On 22/07/2020 07:04, Chris Johns wrote: On 22/7/20 1:04 am, Sebastian Huber wrote: b) As previously discussed there are a few more states a test result can be other than pass and fail and I thikn the wording here may need tightening. I am not sure what is needed. Also how do resource leaks effect the result? Currently, the test framework supports only passed and failed at the level of a test check. I am not sure if adding more states at this level is really helpful. The terms pass and failed are overloaded and relative to a specific context and I am wondering if this needs to be clearer. Yes they are overloaded. For the test framework it is defined what the terms mean for a test check, a test case, and a test suite. If it is not clear from the context, you can say for example "the test check failed". googletest uses these terms: "When using googletest, you start by writing /assertions/, which are statements that check whether a condition is true. An assertion's result can be /success/, /nonfatal failure/, or /fatal failure/. If a fatal failure occurs, it aborts the current function; otherwise the program continues normally." https://github.com/google/googletest/blob/master/googletest/docs/primer.md#basic-concepts ISTQB uses pass/fail: https://glossary.istqb.org/en/search/fail I think we just have to clearly define what the terms mean in our scope and this is what I tried to do. c) Does the framework provide a standard way to export a dynamic test environment so the test and the results can be reviewed as a complete set of data? Sorrry, I don't understand this question. If dynamic configuration effects the test and the test fails would reproducing the result be more difficult if you do not know what the dynamic state was? For example using this for a network test and the dynamic configuration can select between DHCP and a static set up. You could write a log message which tells you the configuration used. The tests can be written in C, so you can do a lot of things. It is up to the writer of the tests to do it properly. [...] a) What is the picture drawn in? Libreoffice Draw. I will comment on the patches as well. Thanks for the review. Sorry, another question, is libtest installed and available to other parts of RTEMS like libbsd and also available to users? Yes, it is installed: project_lib_LIBRARIES += librtemstest.a ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd commands and userspace-header-gen.py
Hello, I see the user commands in libbsd use a generated header file created by `userspace-header-gen.py` however it does not run on my host because I do not have an `elftools` package installed. I cannot find any details on what needs to be installed so this tool can be used. I get the impression it is required to make a new command work. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] libtest: to
On 22/7/20 6:02 pm, Sebastian Huber wrote: > Rename this header file to later move to . The main > feature provided by is the output of standard test > information which is consumed by the RTEMS Tester. Looks good. Thanks for the change. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/33] Test framework improvements
On 22/7/20 7:16 pm, Sebastian Huber wrote: > On 22/07/2020 07:04, Chris Johns wrote: >> On 22/7/20 1:04 am, Sebastian Huber wrote: >> b) As previously discussed there are a few more states a test result can be >> other than pass and fail and I thikn the wording here may need tightening. I >> am >> not sure what is needed. Also how do resource leaks effect the result? > > Currently, the test framework supports only passed and failed at the level of > a > test check. I am not sure if adding more states at this level is really > helpful. The terms pass and failed are overloaded and relative to a specific context and I am wondering if this needs to be clearer. >> c) Does the framework provide a standard way to export a dynamic test >> environment so the test and the results can be reviewed as a complete set of >> data? > Sorrry, I don't understand this question. If dynamic configuration effects the test and the test fails would reproducing the result be more difficult if you do not know what the dynamic state was? For example using this for a network test and the dynamic configuration can select between DHCP and a static set up. >> a) Change "You can add test case destructors with T_add_destructor(). They >> are.." to "A test case destructor can be added with T_add_destructor(). The >> destructors are..". > I kept the "You can" style for now. OK. >> a) Can "You can .." be removed so it is not person specific? For example "You >> can convert time into ticks with the" ciuld be "The time can be converted >> into >> ticks with the"? This comment covers all the "You can"s. :) > I will keep this you can style for now. OK. >> a) What is the picture drawn in? > Libreoffice Draw. >> >> I will comment on the patches as well. > Thanks for the review. Sorry, another question, is libtest installed and available to other parts of RTEMS like libbsd and also available to users? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] trace: Use c++14 instead of c++11 if possible
On Wed, Jul 22, 2020 at 2:26 PM Christian Mauderer
wrote:
> Ping again.
>
> It's clearly not BSP specific. So I would like to get an approval for
> that before pushing it anywhere.
>
CentOS 7's gcc appears to have the option and I would assume this is the
oldest distribution anyone is using.
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Go ahead and push it.
--joel
>
> On 15/06/2020 17:36, Christian Mauderer wrote:
> > Ping.
> >
> > Currently shouldn't be a matter for much hosts (less than 20 including
> > FreeBSD, Fedora, Arch, openSUSE according to distrowatch [1]) but I
> > assume that llvm 10 will spread fast.
> >
> >
> > [1]
> >
> http://distrowatch.org/search.php?pkg=llvm=greaterequal=10=InLatest#pkgsearch
> >
> >
> > On 08/06/2020 08:52, Christian Mauderer wrote:
> >> llvm version 10 uses features from c++14 standard in the headers. With
> >> that, the record/record-main-lttng.cc doesn't build any more. This patch
> >> makes sure that c++14 is used if it is available.
> >> ---
> >> trace/wscript | 6 +-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/trace/wscript b/trace/wscript
> >> index 656f92b..53a1ab4 100644
> >> --- a/trace/wscript
> >> +++ b/trace/wscript
> >> @@ -45,6 +45,7 @@ def configure(conf):
> >> if conf.check(header_name='zlib.h', features='cxx',
> mandatory=False):
> >> conf.check_cxx(lib = 'z')
> >> conf.check_cxx(lib = 'ws2_32', mandatory=False)
> >> +conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
> define_name="HAVE_STD_CXX14")
> >> conf.write_config_header('config.h')
> >>
> >> def build(bld):
> >> @@ -60,7 +61,10 @@ def build(bld):
> >> conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
> >> conf['optflags'] = bld.env.C_OPTS
> >> conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
> >> -conf['cxxflags'] = ['-std=c++11'] + conf['cflags']
> >> +cxxstd = '-std=c++11'
> >> +if bld.env.HAVE_STD_CXX14:
> >> +cxxstd = '-std=c++14'
> >> +conf['cxxflags'] = [cxxstd] + conf['cflags']
> >> conf['linkflags'] = ['-g']
> >> conf['lib'] = []
> >> if bld.env.LIB_WS2_32:
> >>
> > ___
> > 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: [PATCH rtems-tools] trace: Use c++14 instead of c++11 if possible
Ping again.
It's clearly not BSP specific. So I would like to get an approval for
that before pushing it anywhere.
On 15/06/2020 17:36, Christian Mauderer wrote:
> Ping.
>
> Currently shouldn't be a matter for much hosts (less than 20 including
> FreeBSD, Fedora, Arch, openSUSE according to distrowatch [1]) but I
> assume that llvm 10 will spread fast.
>
>
> [1]
> http://distrowatch.org/search.php?pkg=llvm=greaterequal=10=InLatest#pkgsearch
>
>
> On 08/06/2020 08:52, Christian Mauderer wrote:
>> llvm version 10 uses features from c++14 standard in the headers. With
>> that, the record/record-main-lttng.cc doesn't build any more. This patch
>> makes sure that c++14 is used if it is available.
>> ---
>> trace/wscript | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/trace/wscript b/trace/wscript
>> index 656f92b..53a1ab4 100644
>> --- a/trace/wscript
>> +++ b/trace/wscript
>> @@ -45,6 +45,7 @@ def configure(conf):
>> if conf.check(header_name='zlib.h', features='cxx', mandatory=False):
>> conf.check_cxx(lib = 'z')
>> conf.check_cxx(lib = 'ws2_32', mandatory=False)
>> +conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
>> define_name="HAVE_STD_CXX14")
>> conf.write_config_header('config.h')
>>
>> def build(bld):
>> @@ -60,7 +61,10 @@ def build(bld):
>> conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
>> conf['optflags'] = bld.env.C_OPTS
>> conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
>> -conf['cxxflags'] = ['-std=c++11'] + conf['cflags']
>> +cxxstd = '-std=c++11'
>> +if bld.env.HAVE_STD_CXX14:
>> +cxxstd = '-std=c++14'
>> +conf['cxxflags'] = [cxxstd] + conf['cflags']
>> conf['linkflags'] = ['-g']
>> conf['lib'] = []
>> if bld.env.LIB_WS2_32:
>>
> ___
> 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 regarding thread creation in RTEMS
On 22/07/2020 15:36, Richi Dubey wrote:
Threads that get created automatically when a CPU starts have their
scheduler nodes with node->idle set to the thread itself, while the
nodes that are created due to a task being created have NULL in their
node->idle (If not using helper function atm). Am I right?
If yes, Why isn't the function _Scheduler_Set_idle_thread() called
by _Thread_Create_idle_for_CPU?
Trace:
exinit.c -> _Thread_Create_idle -> _Thread_Create_idle_for_CPU
-> _Scheduler_Start_idle -> _Scheduler_EDF_SMP_Start_idle
-> _Scheduler_SMP_Do_start_idle ->_Scheduler_SMP_Release_idle_thread .
I am asking this since _Scheduler_Set_idle_thread() is the only
function that sets the node->idle value.
I think the description of this member is clear:
/**
* @brief Scheduler node for per-thread data.
*/
struct Scheduler_Node {
...
/**
* @brief The idle thread claimed by this node in case the sticky
level is
* greater than zero and the thread is block or is scheduled on another
* scheduler instance.
*
* This is necessary to ensure the priority ceiling protocols work across
* scheduler boundaries.
*/
struct _Thread_Control *idle;
As I said before, the idle threads are normal threads. The only special
thing is that they execute no code which blocks. You really have to
distinguish between threads and scheduler nodes.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Doubt regarding thread creation in RTEMS
Hi, Please clear a doubt of mine. Threads that get created automatically when a CPU starts have their scheduler nodes with node->idle set to the thread itself, while the nodes that are created due to a task being created have NULL in their node->idle (If not using helper function atm). Am I right? If yes, Why isn't the function _Scheduler_Set_idle_thread() called by _Thread_Create_idle_for_CPU? Trace: exinit.c -> _Thread_Create_idle -> _Thread_Create_idle_for_CPU -> _Scheduler_Start_idle -> _Scheduler_EDF_SMP_Start_idle -> _Scheduler_SMP_Do_start_idle ->_Scheduler_SMP_Release_idle_thread . I am asking this since _Scheduler_Set_idle_thread() is the only function that sets the node->idle value. On Wed, Jul 22, 2020 at 1:59 PM Richi Dubey wrote: > This helps. Thanks a lot. > > On Tue, Jul 21, 2020 at 6:55 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 21/07/2020 14:36, Richi Dubey wrote: >> >> > Could you please explain what _User_extensions_Thread_start does? It's >> > hard to understand it all by myself since it has a lot of other >> > information related to objects. >> > >> > The brief for it says: >> > /** >> > * @brief Starts a thread. >> > * >> > * @param created The thread to start. >> > */ >> > >> > This is exactly what my doubt was. When we unlocked the node by >> > setting the state to ready by calling _Thread_Clear_state_locked, >> > shouldn't the node be scheduled if the scheduler sees it fit? Why are >> > we enabling thread dispatch on the current cpu (Shouldn't it depend on >> > the affinity of the thread)? >> > >> > Please tell me what happens in principle after >> > calling _Thread_Clear_state_locked(). >> >> I tried to improve the _Thread_Start() description: >> >> https://lists.rtems.org/pipermail/devel/2020-July/060764.html >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Need help in understanding some of the existing code in RTEMS
Thank you for the clarification.
On Sat, Jul 18, 2020 at 9:06 PM Gedare Bloom wrote:
> On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey wrote:
> >>
> >>
> >> > Scheduler_Node *nodes;
> >> > } Thread_Scheduler_control;
> >> >
> >> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since
> the pointer can point to a single value, why is it being called nodes?
> >> >
> >> See cpukit/score/src/threadinitialize.c +153
> >
> >
> > Thank you for your help.
> > /**
> >* @brief The scheduler nodes of this thread.
> >*
> >* Each thread has a scheduler node for each scheduler instance.
> >*/
> >
> > I went through the entire scheduler related code in threadinitialize.c
> and I understood that the scheduler node which belongs to the scheduler
> that is the home scheduler for a thread gets initialized with the thread's
> priority, while other scheduler nodes gets initialized with the max
> priority : for an idle thread case.
> >
> > But why do we have a scheduler node for each scheduler instance? Is it
> because the thread might migrate to a different processor to facilitate
> helping and would need a node belonging to the scheduler instance which
> owns the processor it is migrating to?
> >
>
> I'm not 100% sure on this, but I believe it is because the thread's
> priority needs to be considered globally when taking
> scheduling/synchronization decisions.
>
> > On Wed, Jul 15, 2020 at 10:12 PM Gedare Bloom wrote:
> >>
> >> On Wed, Jul 15, 2020 at 6:55 AM Richi Dubey
> wrote:
> >> >
> >> > Another quick question:
> >> > typedef struct {
> >> >
> >> > #if defined(RTEMS_SMP)
> >> > ...
> >> > Chain_Control Scheduler_nodes;
> >> >
> >> > #endif
> >> > /**
> >> >* @brief The scheduler nodes of this thread.
> >> >*
> >> >* Each thread has a scheduler node for each scheduler instance.
> >> >*/
> >> > Scheduler_Node *nodes;
> >> > } Thread_Scheduler_control;
> >> >
> >> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since
> the pointer can point to a single value, why is it being called nodes?
> >> >
> >>
> >> See cpukit/score/src/threadinitialize.c +153
> >>
> >>
> >> >
> >> > On Wed, Jul 15, 2020 at 5:57 PM Richi Dubey
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I had a small question. The scheduler struct inside percpu.h looks
> like:
> >> >>
> --
> >> >> struct {
> >> >> /**
> >> >>* @brief The scheduler control of the scheduler owning this
> processor.
> >> >>*
> >> >>* This pointer is NULL in case this processor is currently
> not used by a
> >> >>* scheduler instance.
> >> >>*/
> >> >> const struct _Scheduler_Control *control;
> >> >>
> >> >> /**
> >> >>* @brief The scheduler context of the scheduler owning this
> processor.
> >> >>*
> >> >>* This pointer is NULL in case this processor is currently
> not used by a
> >> >>* scheduler instance.
> >> >>*/
> >> >> const struct Scheduler_Context *context;
> >> >>
> >> >> /**
> >> >>* @brief The idle thread for this processor in case it is
> online and
> >> >>* currently not used by a scheduler instance.
> >> >>*/
> >> >> struct _Thread_Control *idle_if_online_and_unused;
> >> >> } Scheduler;
> >> >>
> --
> >> >> So, does this mean a CPU when active is always either executing an
> idle thread and is not being used by a scheduler (so has a thread attribute
> in the idle_if_online_and_unused), or is used by a scheduler and is
> executing a task ( which can not be an idle task)? Another equivalent
> question is do we have an idle scheduler node, like we have idle predefined
> threads that run on a CPU?
> >> >>
> >>
> >> Not exactly. What I understand is that:
> >> * When a processor is online (active), but not used by a scheduler,
> >> then it executes an idle task.
> >> * When a processor is online and used by a scheduler, it may be
> >> executing any task including an idle task.
> >>
> >> You can find the relevant code in
> cpukit/include/rtems/score/schedulersmpimpl.h
> >>
> >> The idle threads are specially handled when processors are
> >> added/removed from scheduler contexts. A scheduler keeps a chain of
> >> its idle threads:
> >> cpukit/include/rtems/score/schedulersmp.h +64
> >>
> >> >> Please let me know,
> >> >> Thanks.
> >> >>
> >> >> On Tue, Jul 14, 2020 at 8:28 PM Richi Dubey
> wrote:
> >> >>>
> >> >>> I understand. Thank you.
> >> >>>
> >> >>> On Tue, Jul 14, 2020 at 7:05 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 14/07/2020 13:37, Richi Dubey wrote:
> >>
> >> > Here we remove the affine ready queue if it
> >> > exists from the chain of affine queues since now an affine
> thread is
[PATCH v1 1/1] i386: Fix possible race condition on first context restore
Make sure that the esp is restored before the eflags register. When the init task is initially restored, system interrupts are activated when the eflags register is loaded. If the esp register still points to an address in the interrupt stack area (from early system initlization) the ISR might overwrite its own stack. Closes #4030 Closes #4031 --- cpukit/score/cpu/i386/cpu_asm.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/cpu/i386/cpu_asm.S b/cpukit/score/cpu/i386/cpu_asm.S index 6031f6914e..23360959f5 100644 --- a/cpukit/score/cpu/i386/cpu_asm.S +++ b/cpukit/score/cpu/i386/cpu_asm.S @@ -83,9 +83,9 @@ SYM (_CPU_Context_switch): .L_restore: movl I386_CONTEXT_CONTROL_ISR_DISPATCH_DISABLE(eax),ecx movl ecx,PER_CPU_ISR_DISPATCH_DISABLE(edx) +movl REG_ESP(eax),esp /* restore stack pointer */ pushl REG_EFLAGS(eax) /* push eflags */ popf /* restore eflags */ -movl REG_ESP(eax),esp /* restore stack pointer */ movl REG_EBP(eax),ebp /* restore base pointer */ movl REG_EBX(eax),ebx /* restore ebx */ movl REG_ESI(eax),esi /* restore source register */ -- 2.17.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 0/1] i386: Fix possible race condition on first context restore
Ran into this problem sometimes when testing examples of rtems-libbsd, but it should be general. I opened tickets https://devel.rtems.org/ticket/4030 and https://devel.rtems.org/ticket/4031 correspondintly. Cheers, Jan Jan Sommer (1): i386: Fix possible race condition on first context restore cpukit/score/cpu/i386/cpu_asm.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.17.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] eng: Update test framework chapter
Document the dynamic text fixtures, utility functions, and the interrupt
test support. Reorder some sections and reword some paragraphs based on
review comments.
Update #3199.
---
v2:
Address review comments. I updated:
https://ftp.rtems.org/pub/rtems/people/sebh/eng2.pdf
eng/index.rst | 4 +-
eng/test-framework.rst| 412 +-
images/eng/interrupt-test.odg | Bin 0 -> 14829 bytes
images/eng/interrupt-test.pdf | Bin 0 -> 14153 bytes
images/eng/interrupt-test.png | Bin 0 -> 75272 bytes
5 files changed, 313 insertions(+), 103 deletions(-)
create mode 100644 images/eng/interrupt-test.odg
create mode 100644 images/eng/interrupt-test.pdf
create mode 100644 images/eng/interrupt-test.png
diff --git a/eng/index.rst b/eng/index.rst
index 8f91c5e..f6b02ec 100644
--- a/eng/index.rst
+++ b/eng/index.rst
@@ -11,8 +11,8 @@ RTEMS Software Engineering (|version|)
.. topic:: Copyrights and License
-| |copy| 2018, 2019 embedded brains GmbH
-| |copy| 2018, 2019 Sebastian Huber
+| |copy| 2018, 2020 embedded brains GmbH
+| |copy| 2018, 2020 Sebastian Huber
| |copy| 1988, 2015 On-Line Applications Research Corporation (OAR)
.. include:: ../common/license.rst
diff --git a/eng/test-framework.rst b/eng/test-framework.rst
index b6411b5..45db446 100644
--- a/eng/test-framework.rst
+++ b/eng/test-framework.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
-.. Copyright (C) 2018, 2019 embedded brains GmbH
-.. Copyright (C) 2018, 2019 Sebastian Huber
+.. Copyright (C) 2018, 2020 embedded brains GmbH
+.. Copyright (C) 2018, 2020 Sebastian Huber
Software Test Framework
***
@@ -16,6 +16,8 @@ features:
* Implemented in standard C11
+* Tests can be written in C or C++
+
* Runs on at least FreeBSD, MSYS2, Linux and RTEMS
* Test runner and test case code can be in separate translation units
@@ -67,11 +69,11 @@ A `test suite` is a collection of test cases. A `test
case` consists of
individual test actions and checks. A `test check` determines if the outcome
of a test action meets its expectation. A `test action` is a program sequence
with an observable outcome, for example a function invocation with a return
-status. If the test action outcome is all right, then the test check passes,
-otherwise the test check fails. The test check failures of a test case are
-summed up. A test case passes, if the failure count of this test case is zero,
-otherwise the test case fails. The test suite passes if all test cases pass,
-otherwise it fails.
+status. If a test action produces the expected outcome as determined by the
+corresponding test check, then this test check passes, otherwise this test
+check fails. The test check failures of a test case are summed up. A test
+case passes, if the failure count of this test case is zero, otherwise the test
+case fails. The test suite passes if all test cases pass, otherwise it fails.
Test Cases
--
@@ -89,7 +91,7 @@ body:
The test case `name` must be a valid C designator. The test case names must be
unique within the test suite. Just link modules with test cases to the test
runner to form a test suite. The test cases are automatically registered via
-static constructors.
+static C constructors.
.. code-block:: c
:caption: Test Case Example
@@ -144,13 +146,43 @@ macro followed by a function body:
The test case `name` must be a valid C designator. The test case names must be
unique within the test suite. The `fixture` must point to a statically
-initialized read-only object of type `T_fixture`. The test fixture
-provides methods to setup, stop and tear down a test case. A context is passed
-to the methods. The initial context is defined by the read-only fixture
-object. The context can be obtained by the `T_fixture_context()`
-function. It can be set within the scope of one test case by the
-`T_set_fixture_context()` function. This can be used for example to
-dynamically allocate a test environment in the setup method.
+initialized read-only object of type `T_fixture`.
+
+.. code-block:: c
+
+typedef struct T_fixture {
+void (*setup)(void *context);
+void (*stop)(void *context);
+void (*teardown)(void *context);
+void (*scope)(void *context, char *buffer, size_t size);
+void *initial_context;
+} T_fixture;
+
+The test fixture provides methods to setup, stop, and teardown a test case as
+well as the scope for log messages. A context is passed to each of the
+methods. The initial context is defined by the read-only fixture object. The
+context can be obtained by the `T_fixture_context()` function. The context can
+be changed within the scope of one test case by the `T_set_fixture_context()`
+function. The next test case execution using the same fixture will start again
+with the initial context defined by the read-only fixture object. Setting the
+context can be
Re: [PATCH 00/33] Test framework improvements
On 22/07/2020 07:04, Chris Johns wrote: On 22/7/20 1:04 am, Sebastian Huber wrote: This patch set adds a couple of improvements to the test framework: * The header file changes from to . * Support for a stack of test fixtures. This helps to write test building blocks. * The test check messages are now optional. * The support for interrupt tests and change all the interrupt critical tests to use this new test support. This should address the sporadic failures and timeouts. For the documentation please have a look at: https://ftp.rtems.org/pub/rtems/people/sebh/eng2.pdf I assume you asking us to look only at section 8? Yes, and actually only the new sections corresponding to the patch. The doco looks good. The following are some review comment: A full review is also nice ;-) 8.1 a) Supported languages? I added "Tests can be written in C or C++". 8.1.1 a) The wording ".. outcome all right, ..." seems non-specific for someting I would assume needs to be specific. What about " ... is not the required outcome for the test, ..."? I tried to clarify the wording a bit. b) As previously discussed there are a few more states a test result can be other than pass and fail and I thikn the wording here may need tightening. I am not sure what is needed. Also how do resource leaks effect the result? Currently, the test framework supports only passed and failed at the level of a test check. I am not sure if adding more states at this level is really helpful. 8.1.2 a) It test case naming to be specified or can be use anything we like, ie lower case with `_`, Camelcase, ...? It should be CamelCase, but this is a coding style issue which should not be addressed in this part of the documentation. b) Change "static constructors" to "static C constructors". Ok. 8.1.3 a) Change "test case as well as to give thescope for log messags." to " test case as well as the scope for log messages." Ok. b) Change "function. It can be set within the scope of one .." to "function and can be set within the scope of one .." I reworded it a bit based on Gedare's comment. c) Does the framework provide a standard way to export a dynamic test environment so the test and the results can be reviewed as a complete set of data? Sorrry, I don't understand this question. 8.1.4 a) Should "Each non-quiet test check fetches.." be "A non-quiet test check fetches.."? Ok. 8.1.5 a) Change "..if various resources are leaked .." to ".. if various resources have leaked ..". Ok. 8.1.7 a) Change "You can add test case destructors with T_add_destructor(). They are.." to "A test case destructor can be added with T_add_destructor(). The destructors are..". I kept the "You can" style for now. b) Maybe add it is best to use statically allocated memory only? Ok. 8.1.8 a) "Meet its expecation" ... I am not sure what this means, who expecation and what does expecation mean? Do you mean " .. test check meets the check's exepected outcome."? b) I am not sure what "The actual value ..." is referring to. The value the test expects to be the input from the test to the check? Ah coming back to here, I see this is in the next bit. Would adding a little bit in the text before using the special words like actual and expected be helpful? I changed the wording a bit. c) I think the T_assert_ etc variants of the test checks should be explained somewhere. I think it is important to know tests can continue even after a fail or they can be made to stop. I had noted I had not seen this documented and I have now found it buried in here. It split up the "Test Check Variant Conventions" and added a "Test Check Type Conventions". d) I think the word `available` can be removed from the initial sentence on all sub-sectons? This would need a bit of rewording . 8.1.8.10 a) I think type variant piece of test should be moved to the top and add to the initial sentence so you have " are available where the type variant `xyz` must be ...". Ok. 8.1.8.12 a) What about 0 or EINTR as OK? :) 8.1.6 a) Are the printf variants check for type correctness by the compiler? If so I suggest this is mentioned. No, but I think this should be added. 8.1.11 a) Can "You can .." be removed so it is not person specific? For example "You can convert time into ticks with the" ciuld be "The time can be converted into ticks with the"? This comment covers all the "You can"s. :) I will keep this you can style for now. 8.1.13 a) What is the picture drawn in? Libreoffice Draw. I will comment on the patches as well. Thanks for the review. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Doubt regarding thread creation in RTEMS
This helps. Thanks a lot. On Tue, Jul 21, 2020 at 6:55 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 21/07/2020 14:36, Richi Dubey wrote: > > > Could you please explain what _User_extensions_Thread_start does? It's > > hard to understand it all by myself since it has a lot of other > > information related to objects. > > > > The brief for it says: > > /** > > * @brief Starts a thread. > > * > > * @param created The thread to start. > > */ > > > > This is exactly what my doubt was. When we unlocked the node by > > setting the state to ready by calling _Thread_Clear_state_locked, > > shouldn't the node be scheduled if the scheduler sees it fit? Why are > > we enabling thread dispatch on the current cpu (Shouldn't it depend on > > the affinity of the thread)? > > > > Please tell me what happens in principle after > > calling _Thread_Clear_state_locked(). > > I tried to improve the _Thread_Start() description: > > https://lists.rtems.org/pipermail/devel/2020-July/060764.html > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
