On 08.11.18 14:24, Philippe Gerum wrote:
On 11/8/18 2:15 PM, Jan Kiszka wrote:
On 08.11.18 14:09, Philippe Gerum wrote:
On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote:
On 11/5/18 1:20 PM, Jan Kiszka wrote:
The mayday mechanism exists in order to kick a xenomai userspace task
into secondary mode while it is running userspace code. For that, we
ask
I-pipe to call us back when the task was interrupted and is about to
return to userspace.
So far we defer the relaxation from that callback via a VDSO-like
mechanism that triggers a special syscall to the return path of that
very same syscall. However, that is not desirable because it is a
complex, arch-specific mechanism that can easily break and,
specifically, that destroys the backtrace of ptraced tasks.
Fortunately, we can fulfill the needs of mayday also by relaxing
the task directly from the mayday callback. Tested successfully on
x86-64 and ARM.
ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work
properly. This method would cause an interrupt state breakage with any
older ARM patch.
ppc32 is fine back to kernel 4.1 regarding this (did not check earlier
stuff), and arm64 needs the 4.14-based split series to work properly
(4.9 is wrong).
Is the reason for arm64 on 4.9 the same as for arm?
Yes, same pattern.
Is ARM64 on 4.9 considered stable? Then I would look into that path as well.
But given that ARM64 will be newly introduced with 3.1 only and that 4.9 will
likely be out of our legacy maintenance by then, the simpler solution for mayday
topic could just be raising the minimum supported version to 4.14 for that arch
(if there is a real issue).
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
