Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
task. Therefore this patch
Gilles Chanteperdrix wrote:
Another possibility would be to use snprintf instead of strncpy in
xnobject_copy_name, and use xnobject_copy_name here.
Yet another possibility would be to use strlcpy, available in
kernel-space. But it is funny, glibc people does not seem to like
strlcpy for
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
task. Therefore this patch uses the symbolic name.
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
task. Therefore this patch
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is
