Re: [Xenomai] RTDM syscalls & switching

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2016-06-14 18:12, Gilles Chanteperdrix wrote:
> On Tue, Jun 14, 2016 at 06:03:20PM +0200, Jan Kiszka wrote:
>> On 2016-06-14 17:51, Gilles Chanteperdrix wrote:
>>>> Sorry, there *is*: Shadowed thread (anything created by wrapped
>>>> pthread_create) calls, say, read() on some Linux file descriptor, read()
>>>> is wrapped, first probes the call on RTDM, which means migration to RT
>>>> (for currently relaxed threads, like SCHED_WEAK), no RTDM match in the
>>>> kernel, and finally the migration to NRT in order to do the Linux read()
>>>> syscall. That didn't happen with the original design.
>>>
>>> The wrapped read does not get ping-pong when calling the Linux I/O
>>> syscalls. The term syscall means something very precise, and
>>> __wrap_read is not a syscall. It gets ping-pong because it calls
>>> RTDM I/O. But if you call directly Linux I/O syscall, with say
>>> __real_read, you do not get ping-pong. Linux I/O syscall work as
>>> they have always have: they require xenomai threads to run in
>>> secondary mode and will cause them to switch to secondary mode to
>>> handle the syscall.
>>
>> __real_* are a non-portable workarounds for special cases. It's not what
>> Xenomai developers are supposed to use in their applications.
> 
> My argument is that you do not get ping-pong with Linux I/O
> syscalls. And whether __real_* is portable or not does not change
> that fact.

...or by not doing eager migration. The failing RTDM syscall is not for
free either, but it's a different order of magnitude (if not two)
compared to the current execution flow.

> 
>>
>> If it were, we could also give up on wrapping and have rt_task_create
>> etc. again, ie. separate APIs for RT and non-RT.
> 
> Well, actually, I have been thinking about doing exactly that when
> not wrapping: when the application has to call __RT(read) to call
> Xenomai read, there is no reason for this call to fall back to Linux
> read call. The idea came to late, but who knows, I may use it for a
> later version.

Sure, such ideas existed a long time ago already, but then we rather
moved towards seamless integration with Linux and easy porting to/from
Xenomai. If basic things like I/O already requires special care, then we
can indeed go back directly to requiring explicit call tagging. Not
portable either, though a tag like __RT() can be more easily defined
away on native real-time.

That said, such a requirement will not make developers of existing
large, complex, layered applications happy. Like in our case.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux