Re: [Xenomai-help] rtdm_event_timedwait hang-up - SOLVED

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

Philippe Gerum wrote:
> ...
> I'm worried by the fact that mode switching needs to be exposed to the
> application layer in this case. Actually, it has always been seen as an
> internal request, but never as part of the recommended API, because one
> might just do utterly wrong things with this syscall (useless eager
> switch when none is due etc). My worst nightmare waking me up in cold
> sweat is seeing Xenomai-based applications litterally stuffed with
> rt_task_set_mode(...T_PRIMARY...) calls, breaking the lazy switch scheme
> without any upside, but additional latencies. Actually, a lot of work
> has been done to make those mode switches as transparent/invisible as
> possible. My fear is that people having problems with their application
> would start adding mode switches everywhere "just in case", without
> really understanding the logic behind it. Gah...! cold sweat again...
> 
> The other issue which bothers me is that applications would need to know
> the actual implementation of the syscall to pick the right mode, i.e.
> whether rtdm_socket wants to get memory from the Linux pool, or from a
> predefined local pool, and so on. Sounds ok for a low-level library
> which must know about RTDM's internals, but might be error-prone for
> writing regular apps.

That's no RTDM issue, that's up to the driver. And this is also the
place where to document the special feature of selecting the determinism
of service per device. But I'm open to a discussion on this (you may
remember my opinion on non-legacy RT-application design and mode
switching... ;) ), I just have my concerns if this thread is the right
place anymore.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]