Re: [Xenomai-core] [rfc] unit testing context switches.

[Philippe Gerum <rpm@xenomai.org>]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>  > 
>  > Now that the big context switches bugs have been solved, here is a patch
>  > that adds a unit test for context switches and FPU switches
>  > with various type of threads (kernel, user, user in secondary mode,
>  > not using FPU, using FPU, etc...). As is the case of the latency test
>  > there is a small RTDM driver in kernel-space, put in the benchmark
>  > class, even though this test is for unit testing, not for benchmarking.
>  > 
>  > The FPU switches need a small piece of code architecture dependent,
>  > put in <asm/xenomai/fptest.h>, currently only implemented for x86.
>  > 
>  > The kernel-space driver is called xeno_switchtest.ko, the user-space
>  > testing tool is called switchtest, because there is already a context
>  > switch benchmarking tool called "switch".
> 
> Here is an updated version, applying the remarks of Jim and Jan:
> renamed rtbenchmark rttesting, and renamed the already existing context
> switch benchmark switchbench. The patch is large but contains mostly
> renames.
> 
> I would prefer to commit this version before implementing the other
> changes, namely allowing kernel-space non real-time tasks to use the FPU
> and merging the context switches benchmark test with this test.
> 
> +
> +/* Thread type. */
> +typedef enum {
> +    IDLE = 0,
> +    RTK  = 1,        /* kernel-space thread. */
> +    RTUP = 2,        /* user-space real-time thread in primary mode. */
> +    RTUS = 3,        /* user-space real-time thread in secondary mode. */
> +    RTUO = 4,        /* user-space real-time thread oscillating
> +                        between primary and secondary mode. */
> +} threadtype;
> +
> +typedef enum {
> +    FP   = 1,        /* arm the FPU task bit (only make sense for RTK) */
> +    UFPP = 2,        /* use the FPU while in primary mode. */
> +    UFPS = 4         /* use the FPU while in secondary mode. */
> +} fpflags;
> +


IDLE and FP at least look like a bit too generic, potentially subject to 
name clashes. Otherwise, that's fine with me.

-- 

Philippe.