In nOS-V, when a task was paused via the VTp event, two things were
happening: 1) the task state was set to pause and 2) the subsystem state
"Task: Running" was being popped.
This causes a problem when a task calls nosv_submit() in blocking mode,
as it will call nosv_pause() which will emit a VTp event from a
subsystem different than "Task: Running".
To solve this conflict, we handle the subsystems state and the task
state separately with the VTp and VTr events. The subsystem state "Task:
Running" no longer is connected to the state of the task and only shows
if we entered the body of the task or not. It has now been renamed to
"Task: In body".
The new state "Task: In body" represents that the task body has begun
the execution and is still in the stack, but the task may be paused. The
subsystem is not changed by the VTp (pause) or VTr (resume) events.
Fixes: https://pm.bsc.es/gitlab/rarias/ovni/-/issues/128
This commit introduces the OVNI_TRACEDIR environment variable to change
the directory where traces are generated. By default, when the envar is
not defined, the trace is still generated in the ovni directory. The
envar can take a trace directory name, a relative path to the directory,
or its absolute path. In the first case, the directory is created in the
current path $PWD.
Both libovni (rt) and ovnisync read this environment variable.
Adds ovni_version_check() to test the version at runtime, set the
SONAME to the major version and install a symlinks to the complete
version:
libovni.so -> libovni.so.1
libovni.so.1 -> libovni.so.1.0.0
libovni.so.1.0.0
The emulator cannot handle tasks that are executed multiple times and
concurrently. The task for executes a single task (with unique id) multiple
times by using different arguments. The task model needs to be extended to
support the taskfor clause properly. In the meanwhile, we simple set the
subsystem to be running a taskfor.
These events only show if a thread has been removed from the CPU, but
doesn't provide information about what other thread caused the context
switch. This type of information can be obtained even with strict
/proc/sys/kernel/perf_event_paranoid settings.
