Until now, the value returned by ovni_thread_isready() was still
non-zero when the thread stream was destroyed in ovni_thread_free()
This was making it impossible to detect when a stream was destroyed.
This change makes it return 0 after ovni_thread_free() by using a new
finished flag. The flag keeps track on then the stream is destroyed,
preventing double initialization of a free stream.
Causes the packages to always appear as found or not found in the
summary of cmake. Otherwise they were only checked if the compiler
supports the -fompss2 flag.
When running ovniver without LD_LIBRARY_PATH set, the loader couldn't
find any ovni installation and therefore was failing to start the
program. With this change we set the RUNPATH (not RPATH) of ovniver to
the installation libdir, so when no other libovni library is loaded via
LD_LIBRARY_PATH the one provided by the same source as ovniver is used.
The value of LD_LIBRARY_PATH is also printed so we can determine where
it may be loading libovni. Using LD_DEBUG=libs will give more
information of the search process.
Fixes: https://pm.bsc.es/gitlab/rarias/ovni/-/issues/163
The experimental flag -a is used to ease the transition to the usage of
ovni_thread_require(), as it may be posible to have traces in which not
all libraries have requested their model. The flag causes all emulation
models to be enabled. This flag is considered experimental and it may be
removed or renamed in future versions.
The emulator will now check that all threads are properly finalyzed by
calling ovni_thread_free(), as required by the specification. For now
only a warning is issued, which is enough to determine the cause of
potential emulator panics.
The ovni model is now always enabled.
Allows programs to update to a new libovni library without breaking the
instrumentation. Only until the first call to ovni_thread_require() the
models are enabled on demand.
Until now, emulation models were always being registered via probe(),
which causes the emulator to initialize all the channels. To reduce the
overhead, the channels were not connected or registered in the bay
until the first event of that model was received. This delayed connect
was causing issues in muxes where the newly connected model required
refreshing the touched channels. Which in turn was causing unexpected
PRV events.
By determining which models we need to enable, we can remove the delayed
connect mechanism and just enable those models at initialization time,
and connect the channels.
When running without all the subsystem events enabled in nOS-V, it is
possible to emit two consecutive VTx events, which would push twice the
same value ST_TASK_BODY into the subsystem channel. This change relaxes
the subsystem channel to accept duplicate stacked values. A regression
test is also added.
Reported-By: Raúl Peñacoba Veigas <raul.penacoba@bsc.es>
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
The check_clock_gate() was trying to access to the first event in all
streams. However, streams that are empty don't have any event, so they
cause a NULL dereference. Skipping not active streams avoids the
problem.
Tests can now specify a DRIVER option pointing to a shell script that
will run instead of the default driver. It allows tests to run any
commands and run the emulator several times or with different
environment variables.
The full path of the test program is available in the OVNI_TEST_PATH
environment variable.
