Re: [Xenomai-help] Writing from user space direct to IO Ports without mode switches

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

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

Vincent Levesque wrote:
> Hi Philippe,
>> Excepts from your code:
>>   while(!end){
>>     //switch to primary mode
>>     ret = rt_task_set_mode(0, T_PRIMARY, NULL);
>>
>> Damnit. I knew this particular interface was going to be misused most of
>> the time. In short: do ____NOT_____ switch modes manually, this is
>> useless because Xenomai syscalls do it for you, and even sub-optimal
>> because the kernel knows better when it needs it and saves you a syscall
>> when required. The T_PRIMARY bit has been solely provided for internal
>> Xenomai purposes (some Xenomai libs have very special requirements in
>> very rare cases). rt_task_wait_period() will switch to primary mode if
>> needed, and always leave you in primary upon return.
>>   
> Indeed, I was also doing the same thing. From my understanding of the 
> docs, I assumed that manually setting a task to secondary mode was 
> allowed and could improve performance. Take for instance a task that 

Yes, it is allowed, but no, it doesn't improve performance.

> logs data coming from a RT_QUEUE to a file. Is there anything special 
> that should be done to minimize the impact of the frequent mode switches 
> in such a case?

As I once requested that mode switching feature, let my clarify its only
intended use case: RTDM devices may provide different support for
certain services (open/close/ioctl etc.) depending on the caller's
context. In order to let the caller control his context cleanly (ie.
without trickery to trigger automatic switches) in case there is support
for both modes for some device service, we introduced the explicit
switch interface. Really, this is the only scenario where switching
manually makes sense with Xenomai, and it is a corner case even under RTDM.

In all other cases, as Philippe explained, the Xenomai core will switch
for you transparently and efficiently. That even includes RTDM devices
which only support some service in one mode. E.g., rt_dev_read will
switch the caller to primary mode if the involved driver only provides a
read_rt handler and the caller was in secondary mode.

If you want to make your mode switches efficient, design your
applications in a way that you don't interleave Linux services with
blocking Xenomai services needlessly. Means, design the loop of your
borderline thread such that it only switches once to secondary mode and
back per cycle. But it sounds like your application (minus manual mode
switches) is already designed that way.

Hope that helped to clarify the situation. Now please let us know which
sentence(s) from the doc may have misled your understanding of the mode
switching feature. Maybe we have to rephrase them.

Jan


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