Jan Kiszka wrote:
Petr Cervenka wrote:
The problem was in my calling "RT" task. I forgot to switch the new
created task to PRIMARY MODE, because I didn't know it's neccessary.
As Philippe said, it isn't usually required - with exceptions. Let me
first sketch the standard situation: You registered a read_rt handler
with your device, but no read_nrt. If your application now calls
rt_dev_read (or just read() for the POSIX skin) from the "wrong"
context, RTDM will detect the missing _nrt handler and trigger an
automatic switch to primary mode (and vice versa). So, no need for
manual switching in the standard case.
But if you had registered handlers for both contexts, RTDM will always
invoke the one for your current mode.
I wonder if marking the call as "conforming" instead of leaving it to
the current domain would make such handling more intuitive? RT threads
would automatically switch to primary before always going to the _rt
routine, while plain Linux tasks would just go to the _nrt one. Am I
off-base wrt RTDM's logic here?
This means your _nrt handler must
handle this mode correctly! This "sticky" behaviour was invented to
allow providing services both with and without strict determinism. RT
handler may allocate required resources from pre-allocated but limited
pools, NRT handlers are free to use Linux services for this. This is
used in practice e.g. by the 16550A driver or RTnet.
It may appear a bit tricky for IOCTL handlers to implement this scheme,
as the actual service demultiplexing happens inside the handler, and
there might be some IOCTLs exclusively for RT and some only for NRT. In
this case, just reject wrong context invocations by returning -ENOSYS.
RTDM will then re-invoke the service after toggling the context. See the
IOCTL handling of the timerbench driver as example.
I still have same problems with porting the driver, but I think I can
handle them myself.
Thanks for your help.
Petr Cervenka
Jan
------------------------------------------------------------------------
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
