[Xenomai-help] rtdm_event_timedwait hang-up

[Xenomai-help] rtdm_event_timedwait hang-up

[Petr Cervenka]

Hello,
I'm trying to port a  driver of a AD card to RTDM.
When I use rtdm_event_timedwait in IOCTL handler (called from NRT user app), the system will hang-up immediately.
Does it have something to do with: https://mail.gna.org/public/xenomai-help/2006-03/msg00035.html
, ie. it's not possible to call wait /caller blocking functions from non-real-time, is it?
Is there a posibility to do some workaround to solve this or other alternative. I need to wait couple of seconds for IRQ from device.

My configuration: kernel-2.6.15.6, adeos-ipipe-2.6.15-i386-1.2-01, xenomai-2.1.0
Thanks for any help

Petr Cervenka

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

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

Petr Cervenka wrote:
> Hello,
> I'm trying to port a  driver of a AD card to RTDM.
> When I use rtdm_event_timedwait in IOCTL handler (called from NRT user app), the system will hang-up immediately.
> Does it have something to do with: https://mail.gna.org/public/xenomai-help/2006-03/msg00035.html
> , ie. it's not possible to call wait /caller blocking functions from non-real-time, is it?

Yep, that's exactly the point, it's an illegal usage.

And the fact that this still causes a crash instead of some more
graceful failure reminds me of one reason why I asked for the new
XENO_ASSERT macro: adding debug checks for such mistakes to RTDM.

> Is there a posibility to do some workaround to solve this or other alternative. I need to wait couple of seconds for IRQ from device.

A) turn the waiter into a xenomai shadow thread, even if it will wait
for several seconds without hard timing constraints (use priority 1 e.g.)

B) signal the event arrival via rtdm_nrtsig to a Linux handler which
could in turn wake up a non-RT waiter blocking on standard Linux
wait_queue or so

The latter options involves more work and code and should only be picked
if A) is really not desired.

> 
> My configuration: kernel-2.6.15.6, adeos-ipipe-2.6.15-i386-1.2-01, xenomai-2.1.0
> Thanks for any help
> 
> Petr Cervenka
> 

Jan


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

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Philippe Gerum]

Jan Kiszka wrote:
> Petr Cervenka wrote:
> 
>>Hello,
>>I'm trying to port a  driver of a AD card to RTDM.
>>When I use rtdm_event_timedwait in IOCTL handler (called from NRT user app), the system will hang-up immediately.
>>Does it have something to do with: https://mail.gna.org/public/xenomai-help/2006-03/msg00035.html
>>, ie. it's not possible to call wait /caller blocking functions from non-real-time, is it?
> 
> 
> Yep, that's exactly the point, it's an illegal usage.
> 
> And the fact that this still causes a crash instead of some more
> graceful failure reminds me of one reason why I asked for the new
> XENO_ASSERT macro: adding debug checks for such mistakes to RTDM.
>

It would be nice to have all potentially blocking syscalls actively 
checking for invalid call context, so that we always get graceful 
returns. At least, I'm in the process of adding the missing checks to 
the traditional RTOS skins which I'm extending with a native syscall 
interface. The good news is that it's basically a matter of grepping 
xnsynch_sleep_on() in the codebase.

--- skins/rtdm/drvlib.c	(revision 765)
+++ skins/rtdm/drvlib.c	(working copy)
@@ -648,6 +648,11 @@
      else if (!__test_and_clear_bit(0, &event->pending)) {
          xnthread_t  *thread = xnpod_current_thread();

+	if (xnpod_unblockable_p()) {
+	    err = -EPERM;
+	    goto unlock_and_exit;
+	}
+
          xnsynch_sleep_on(&event->synch_base, XN_INFINITE);

          if (!xnthread_test_flags(thread, XNRMID|XNBREAK))
@@ -658,6 +663,7 @@
              err = -EINTR;
      }

+ unlock_and_exit:
      xnlock_put_irqrestore(&nklock, s);

      return err;
-- 

Philippe.

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Petr Cervenka wrote:
>>
>>> Hello,
>>> I'm trying to port a  driver of a AD card to RTDM.
>>> When I use rtdm_event_timedwait in IOCTL handler (called from NRT
>>> user app), the system will hang-up immediately.
>>> Does it have something to do with:
>>> https://mail.gna.org/public/xenomai-help/2006-03/msg00035.html
>>> , ie. it's not possible to call wait /caller blocking functions from
>>> non-real-time, is it?
>>
>>
>> Yep, that's exactly the point, it's an illegal usage.
>>
>> And the fact that this still causes a crash instead of some more
>> graceful failure reminds me of one reason why I asked for the new
>> XENO_ASSERT macro: adding debug checks for such mistakes to RTDM.
>>
> 
> It would be nice to have all potentially blocking syscalls actively
> checking for invalid call context, so that we always get graceful
> returns. At least, I'm in the process of adding the missing checks to
> the traditional RTOS skins which I'm extending with a native syscall
> interface. The good news is that it's basically a matter of grepping
> xnsynch_sleep_on() in the codebase.
> 
> --- skins/rtdm/drvlib.c    (revision 765)
> +++ skins/rtdm/drvlib.c    (working copy)
> @@ -648,6 +648,11 @@
>      else if (!__test_and_clear_bit(0, &event->pending)) {
>          xnthread_t  *thread = xnpod_current_thread();
> 
> +    if (xnpod_unblockable_p()) {
> +        err = -EPERM;
> +        goto unlock_and_exit;
> +    }
> +
>          xnsynch_sleep_on(&event->synch_base, XN_INFINITE);
> 
>          if (!xnthread_test_flags(thread, XNRMID|XNBREAK))
> @@ -658,6 +663,7 @@
>              err = -EINTR;
>      }
> 
> + unlock_and_exit:
>      xnlock_put_irqrestore(&nklock, s);
> 
>      return err;

Agree, but I prefer to be able to switch those checks off when the used
drivers have been verified for correctness.

Actually, this check is up to them: when some service is invoked from
the "wrong" context, the driver can return -ENOSYS to let Xenomai switch
to the right one. It can also return some other error to the user
instead. Or it can block certain contexts by not registering related
service handlers.

As the user never invokes RTDM services directly, I see no need for
permanent checks. The Linux kernel does such checking also on demand,
not by default.

Jan


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

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Petr Cervenka wrote:
>>>
>>>
>>>>Hello,
>>>>I'm trying to port a  driver of a AD card to RTDM.
>>>>When I use rtdm_event_timedwait in IOCTL handler (called from NRT
>>>>user app), the system will hang-up immediately.
>>>>Does it have something to do with:
>>>>https://mail.gna.org/public/xenomai-help/2006-03/msg00035.html
>>>>, ie. it's not possible to call wait /caller blocking functions from
>>>>non-real-time, is it?
>>>
>>>
>>>Yep, that's exactly the point, it's an illegal usage.
>>>
>>>And the fact that this still causes a crash instead of some more
>>>graceful failure reminds me of one reason why I asked for the new
>>>XENO_ASSERT macro: adding debug checks for such mistakes to RTDM.
>>>
>>
>>It would be nice to have all potentially blocking syscalls actively
>>checking for invalid call context, so that we always get graceful
>>returns. At least, I'm in the process of adding the missing checks to
>>the traditional RTOS skins which I'm extending with a native syscall
>>interface. The good news is that it's basically a matter of grepping
>>xnsynch_sleep_on() in the codebase.
>>
>>--- skins/rtdm/drvlib.c    (revision 765)
>>+++ skins/rtdm/drvlib.c    (working copy)
>>@@ -648,6 +648,11 @@
>>     else if (!__test_and_clear_bit(0, &event->pending)) {
>>         xnthread_t  *thread = xnpod_current_thread();
>>
>>+    if (xnpod_unblockable_p()) {
>>+        err = -EPERM;
>>+        goto unlock_and_exit;
>>+    }
>>+
>>         xnsynch_sleep_on(&event->synch_base, XN_INFINITE);
>>
>>         if (!xnthread_test_flags(thread, XNRMID|XNBREAK))
>>@@ -658,6 +663,7 @@
>>             err = -EINTR;
>>     }
>>
>>+ unlock_and_exit:
>>     xnlock_put_irqrestore(&nklock, s);
>>
>>     return err;
> 
> 
> Agree, but I prefer to be able to switch those checks off when the used
> drivers have been verified for correctness.
> 
> Actually, this check is up to them: when some service is invoked from
> the "wrong" context, the driver can return -ENOSYS to let Xenomai switch
> to the right one. It can also return some other error to the user
> instead. Or it can block certain contexts by not registering related
> service handlers.

I agree; there are some RTDM specific issues, especially the adaptive calls.

> 
> As the user never invokes RTDM services directly, I see no need for
> permanent checks. The Linux kernel does such checking also on demand,
> not by default.
>

Yes, but the kernel usually don't go south when a user-level app does a 
mistake. We currently do.

> Jan
> 


-- 

Philippe.

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Petr Cervenka wrote:
>>>>
>>>>
>>>>> Hello,
>>>>> I'm trying to port a  driver of a AD card to RTDM.
>>>>> When I use rtdm_event_timedwait in IOCTL handler (called from NRT
>>>>> user app), the system will hang-up immediately.
>>>>> Does it have something to do with:
>>>>> https://mail.gna.org/public/xenomai-help/2006-03/msg00035.html
>>>>> , ie. it's not possible to call wait /caller blocking functions from
>>>>> non-real-time, is it?
>>>>
>>>>
>>>> Yep, that's exactly the point, it's an illegal usage.
>>>>
>>>> And the fact that this still causes a crash instead of some more
>>>> graceful failure reminds me of one reason why I asked for the new
>>>> XENO_ASSERT macro: adding debug checks for such mistakes to RTDM.
>>>>
>>>
>>> It would be nice to have all potentially blocking syscalls actively
>>> checking for invalid call context, so that we always get graceful
>>> returns. At least, I'm in the process of adding the missing checks to
>>> the traditional RTOS skins which I'm extending with a native syscall
>>> interface. The good news is that it's basically a matter of grepping
>>> xnsynch_sleep_on() in the codebase.
>>>
>>> --- skins/rtdm/drvlib.c    (revision 765)
>>> +++ skins/rtdm/drvlib.c    (working copy)
>>> @@ -648,6 +648,11 @@
>>>     else if (!__test_and_clear_bit(0, &event->pending)) {
>>>         xnthread_t  *thread = xnpod_current_thread();
>>>
>>> +    if (xnpod_unblockable_p()) {
>>> +        err = -EPERM;
>>> +        goto unlock_and_exit;
>>> +    }
>>> +
>>>         xnsynch_sleep_on(&event->synch_base, XN_INFINITE);
>>>
>>>         if (!xnthread_test_flags(thread, XNRMID|XNBREAK))
>>> @@ -658,6 +663,7 @@
>>>             err = -EINTR;
>>>     }
>>>
>>> + unlock_and_exit:
>>>     xnlock_put_irqrestore(&nklock, s);
>>>
>>>     return err;
>>
>>
>> Agree, but I prefer to be able to switch those checks off when the used
>> drivers have been verified for correctness.
>>
>> Actually, this check is up to them: when some service is invoked from
>> the "wrong" context, the driver can return -ENOSYS to let Xenomai switch
>> to the right one. It can also return some other error to the user
>> instead. Or it can block certain contexts by not registering related
>> service handlers.
> 
> I agree; there are some RTDM specific issues, especially the adaptive
> calls.
> 
>>
>> As the user never invokes RTDM services directly, I see no need for
>> permanent checks. The Linux kernel does such checking also on demand,
>> not by default.
>>
> 
> Yes, but the kernel usually don't go south when a user-level app does a
> mistake. We currently do.

Regarding RTDM, we only do this when the driver fails on its job, and
that's "normal" for all monolithic kernels.

OK, I will prepare the checks based on XENO_ASSERT. To make sure I pick
the right expressions:

!xnpod_unblockable_p():
- allows blockable RT-context (kernel and user threads)
- rejects user threads in secondary mode
- rejects Linux threads

xnpod_root_p():
- allows Linux threads (kerne and user)
- allows threads in secondary mode
- rejects the rest

Right?

Jan


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

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

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

Petr Cervenka wrote:
> Hello,
> I'm trying to port a  driver of a AD card to RTDM.

The discussion around blockable contexts made me forget to ask some
question:

I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
don't know the current status. Anyway, have you considered that
abstraction model for your driver? Is there already a COMEDI driver for
your card in COMEDI? Maybe it's more useful then to through all efforts
together and get a generic solution running.

Jan


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

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Philippe Gerum]

Jan Kiszka wrote:
> Petr Cervenka wrote:
> 
>>Hello,
>>I'm trying to port a  driver of a AD card to RTDM.
> 
> 
> The discussion around blockable contexts made me forget to ask some
> question:
> 
> I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
> don't know the current status.

Indeed. The rumour is called Alex.

  Anyway, have you considered that
> abstraction model for your driver? Is there already a COMEDI driver for
> your card in COMEDI? Maybe it's more useful then to through all efforts
> together and get a generic solution running.
> 
> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Petr Cervenka wrote:
>>
>>> Hello,
>>> I'm trying to port a  driver of a AD card to RTDM.
>>
>>
>> The discussion around blockable contexts made me forget to ask some
>> question:
>>
>> I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
>> don't know the current status.
> 
> Indeed. The rumour is called Alex.
> 

Yes, I know. I just don't wanted to drag someone to public, saying: "Hey
man, already doing your job?" ;)

But, as we all know him now, what is the current status then?

Jan


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

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Petr Cervenka wrote:
>>>
>>>
>>>>Hello,
>>>>I'm trying to port a  driver of a AD card to RTDM.
>>>
>>>
>>>The discussion around blockable contexts made me forget to ask some
>>>question:
>>>
>>>I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
>>>don't know the current status.
>>
>>Indeed. The rumour is called Alex.
>>
> 
> 
> Yes, I know. I just don't wanted to drag someone to public, saying: "Hey
> man, already doing your job?" ;)
> 

It's part of the anti-shyness treatment I'm administering to Alex...

> But, as we all know him now, what is the current status then?
> 
> Jan
> 


-- 

Philippe.

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Petr Cervenka]

I' tried to create  user realtime task, and after all effort (and many related partial problems solved) I still cannot do blocking variant of rtdm_event_timedwait.
1) How can I recognize, that the function is called within proper context / ie. is there an rtdm equivalent to xnpod_unblockable_p?
2) Could be the problem elsewhere?
3) My General Standards PCI-24DSI-12 card is not supported by comedi. And I'm not familiar with it either. The original driver is not so complicated and the port looked as easy work ;-) But waiting inside ioctl or read handler for an interrupt is critical for proper functionality.
4) I realized when I make a realtime task (prio 1 ~ lowest, I hope) and in my main (nrt) task I call sleep(1), It will fall asleep forever (or maybe to some signal).
5) Is it possible to set some event or to send signal/message/... from rt to nrt and back?
6) Is there some easy-to-understand documentation? What I can or cannot...?
Petr Cervenka

>
>  Petr Cervenka wrote:
> > Hello,
> > I'm trying to port a  driver of a AD card to RTDM.
> 
> The discussion around blockable contexts made me forget to ask some
> question:
> 
> I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
> don't know the current status. Anyway, have you considered that
> abstraction model for your driver? Is there already a COMEDI driver for
> your card in COMEDI? Maybe it's more useful then to through all efforts
> together and get a generic solution running.
> 
> Jan
> 
> 
> 

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 2981 bytes --]

Petr Cervenka wrote:
> I' tried to create  user realtime task, and after all effort (and
> many related partial problems solved) I still cannot do blocking
> variant of rtdm_event_timedwait.
> 1) How can I recognize, that the function is called within proper
> context / ie. is there an rtdm equivalent to xnpod_unblockable_p?

First of all, there is the concept of the dual entry points, one for RT
(xxx_rt), the other for non-RT (xxx_nrt). If your driver only registers
a handler on xxx_rt, it will never get called in unblockable context. If
it registers different functions on those entry points, it can easily
tell the contexts apart.

Given that you have some significant amount of code to share between a
RT and a non-RT invocation, you can register the same handler on both
entry points. Then rtdm_in_rt_context() will tell you in which context
you currently are.

> 2) Could be the problem elsewhere?

I prepared the attached patch that catches illegal service
invocations. It will get checked in as soon as we decided how to switch
XENO_ASSERTs on. For now this is done via CONFIG_XENO_OPT_DEBUG. Feel
free to apply it on your Xenomai code and check if it's useful. I tested
it a bit, and it didn't break anything of RTDM in an obvious way. :)

> 3) My General Standards PCI-24DSI-12 card is not supported by comedi.
> And I'm not familiar with it either. The original driver is not so
> complicated and the port looked as easy work ;-) But waiting inside

I can understand that you do not want to complicate your job with comedi
when there is no support for your hardware anyway.

> ioctl or read handler for an interrupt is critical for proper
> functionality.

This must work. See the 16550A driver e.g., it has a similar design,
specifically for handling RTSER_RTIOC_WAIT_EVENT.

> 4) I realized when I make a realtime task (prio 1 ~ lowest, I hope)
> and in my main (nrt) task I call sleep(1), It will fall asleep
> forever (or maybe to some signal).

Sounds like something is blocking the Linux timer. Did you accidentally
register your driver on it? See /proc/interrupts for the timer IRQ
counter, in contrast to /proc/xenomai/irq.

> 5) Is it possible to set some event or to send signal/message/...
> from rt to nrt and back?

rt->nrt: rtdm_nrtsig_xxx
nrt->rt: any blocking rtdm-IPC service (except for mutexes of course)
can be signalled also from non-rt

> 6) Is there some easy-to-understand documentation? What I can or
> cannot...?

Did you browse the API documentation of RTDM, maybe also had a look at
the related RTDM-and-Applications.pdf (hmm, were does a user get this
from? At least, it's in the SVN, but the homepage still requires an
update...)? If yes, please let us know what remains unclear and what
would be additionally desirable. A tour on RTDM, like Philippe already
wrote for other subsystems, would be nice - it just takes someone to
write it...

> Petr Cervenka
> 

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: rtdm-asserts.patch --]
[-- Type: text/x-patch; name="rtdm-asserts.patch", Size: 8128 bytes --]

Index: include/rtdm/rtdm_driver.h
===================================================================
--- include/rtdm/.svn/text-base/rtdm_driver.h.svn-base	2006-03-09 22:16:03.000000000 +0100
+++ include/rtdm/rtdm_driver.h	2006-03-20 17:55:10.000000000 +0100
@@ -38,6 +38,7 @@
 #include <nucleus/heap.h>
 #include <nucleus/pod.h>
 #include <nucleus/synch.h>
+#include <nucleus/assert.h>
 #include <rtdm/rtdm.h>
 
 
@@ -890,6 +891,7 @@ static inline rtdm_task_t *rtdm_task_cur
 
 static inline int rtdm_task_wait_period(void)
 {
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
     return xnpod_wait_thread_period(NULL);
 }
 
Index: include/nucleus/assert.h
===================================================================
--- include/nucleus/.svn/text-base/assert.h.svn-base	2006-03-08 00:48:14.000000000 +0100
+++ include/nucleus/assert.h	2006-03-20 20:04:10.000000000 +0100
@@ -22,18 +22,14 @@
 
 #include <nucleus/compiler.h>
 
-#ifndef CONFIG_XENO_OPT_DEBUG_LEVEL
-#define CONFIG_XENO_OPT_DEBUG_LEVEL  0
-#endif
-
-#if CONFIG_XENO_OPT_DEBUG_LEVEL > 0
+#if CONFIG_XENO_OPT_DEBUG
 #define XENO_ASSERT(cond,action)  do { \
 if (unlikely((cond) != 0)) \
 	do { action; } while(0); \
 } while(0)
-#else  /* CONFIG_XENO_OPT_DEBUG_LEVEL == 0 */
+#else  /* !CONFIG_XENO_OPT_DEBUG */
 #define XENO_ASSERT(cond,action) do { } while(0)
-#endif /* CONFIG_XENO_OPT_DEBUG_LEVEL > 0 */
+#endif /* CONFIG_XENO_OPT_DEBUG */
 
 #define XENO_BUGON(cond)  \
     XENO_ASSERT(cond,xnpod_fatal("assertion failed at %s:%d",__FILE__,__LINE__))
Index: ksrc/skins/rtdm/drvlib.c
===================================================================
--- ksrc/skins/rtdm/.svn/text-base/drvlib.c.svn-base	2006-03-13 23:13:19.000000000 +0100
+++ ksrc/skins/rtdm/drvlib.c	2006-03-20 20:11:38.000000000 +0100
@@ -279,6 +279,8 @@ void rtdm_task_join_nrt(rtdm_task_t *tas
     spl_t s;
 
 
+    XENO_ASSERT(xnpod_root_p(), return;);
+
     xnlock_get_irqsave(&nklock, s);
 
     while (!xnthread_test_flags(task, XNZOMBIE)) {
@@ -305,6 +307,9 @@ EXPORT_SYMBOL(rtdm_task_join_nrt);
  * - -EINTR is returned if calling task has been unblock by a signal or
  * explicitely via rtdm_task_unblock().
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -319,6 +324,8 @@ int rtdm_task_sleep(uint64_t delay)
     xnthread_t  *thread = xnpod_current_thread();
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnpod_suspend_thread(thread, XNDELAY, xnpod_ns2ticks(delay), NULL);
 
     return xnthread_test_flags(thread, XNBREAK) ? -EINTR : 0;
@@ -337,6 +344,9 @@ EXPORT_SYMBOL(rtdm_task_sleep);
  * - -EINTR is returned if calling task has been unblock by a signal or
  * explicitely via rtdm_task_unblock().
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -354,6 +364,8 @@ int rtdm_task_sleep_until(uint64_t wakeu
     int         err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     delay = xnpod_ns2ticks(wakeup_time) - xnpod_get_time();
@@ -626,6 +638,9 @@ EXPORT_SYMBOL(rtdm_event_signal);
  *
  * - -EIDRM is returned if @a event has been destroyed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -641,6 +656,8 @@ int rtdm_event_wait(rtdm_event_t *event)
     int     err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     if (testbits(event->synch_base.status, SYNCH_DELETED))
@@ -689,6 +706,9 @@ EXPORT_SYMBOL(rtdm_event_wait);
  *
  * - -EIDRM is returned if @a event has been destroyed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -706,6 +726,8 @@ int rtdm_event_timedwait(rtdm_event_t *e
     int         err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     if (unlikely(testbits(event->synch_base.status, SYNCH_DELETED)))
@@ -810,6 +832,9 @@ void rtdm_sem_destroy(rtdm_sem_t *sem);
  *
  * - -EIDRM is returned if @a sem has been destroyed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -825,6 +850,8 @@ int rtdm_sem_down(rtdm_sem_t *sem)
     int     err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     if (testbits(sem->synch_base.status, SYNCH_DELETED))
@@ -878,6 +905,9 @@ EXPORT_SYMBOL(rtdm_sem_down);
  *
  * - -EIDRM is returned if @a sem has been destroyed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -895,6 +925,8 @@ int rtdm_sem_timeddown(rtdm_sem_t *sem, 
     int         err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     if (testbits(sem->synch_base.status, SYNCH_DELETED))
@@ -1035,6 +1067,9 @@ void rtdm_mutex_destroy(rtdm_mutex_t *mu
  *
  * - -EIDRM is returned if @a mutex has been destroyed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -1050,6 +1085,8 @@ int rtdm_mutex_lock(rtdm_mutex_t *mutex)
     int     err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     if (testbits(mutex->synch_base.status, SYNCH_DELETED))
@@ -1097,6 +1134,9 @@ EXPORT_SYMBOL(rtdm_mutex_lock);
  *
  * - -EIDRM is returned if @a mutex has been destroyed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -1114,6 +1154,8 @@ int rtdm_mutex_timedlock(rtdm_mutex_t *m
     int         err = 0;
 
 
+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
+
     xnlock_get_irqsave(&nklock, s);
 
     if (testbits(mutex->synch_base.status, SYNCH_DELETED))
@@ -1179,6 +1221,8 @@ void rtdm_mutex_unlock(rtdm_mutex_t *mut
     spl_t s;
 
 
+    XENO_ASSERT(!xnpod_asynch_p(), return;);
+
     xnlock_get_irqsave(&nklock, s);
 
     __clear_bit(0, &mutex->locked);
@@ -1426,6 +1470,9 @@ static struct file_operations rtdm_mmap_
  * - -EAGAIN is returned if too much memory has been already locked by the
  * user process.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * @note RTDM supports two models for unmapping the user memory range again.
  * One is explicite unmapping via rtdm_munmap(), either performed when the
  * user requests it via an IOCTL etc. or when the related device is closed.
@@ -1457,6 +1504,9 @@ int rtdm_mmap_to_user(rtdm_user_info_t *
     void                    *old_priv_data;
     void                    *user_ptr;
 
+
+    XENO_ASSERT(xnpod_root_p(), return -EPERM;);
+
     filp = filp_open("/dev/zero", O_RDWR, 0);
     if (IS_ERR(filp))
         return PTR_ERR(filp);
@@ -1499,6 +1549,9 @@ EXPORT_SYMBOL(rtdm_mmap_to_user);
  *
  * - -EINVAL is returned if an invalid address or size was passed.
  *
+ * - -EPERM @e may be returned if an illegal invocation environment is
+ * detected.
+ *
  * Environments:
  *
  * This service can be called from:
@@ -1512,6 +1565,9 @@ int rtdm_munmap(rtdm_user_info_t *user_i
 {
     int err;
 
+
+    XENO_ASSERT(xnpod_root_p(), return -EPERM;);
+
     down_write(&user_info->mm->mmap_sem);
     err = do_munmap(user_info->mm, (unsigned long)ptr, len);
     up_write(&user_info->mm->mmap_sem);

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

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jeff Webb]

Jan Kiszka wrote:
> Did you browse the API documentation of RTDM, maybe also had a look at
> the related RTDM-and-Applications.pdf (hmm, were does a user get this
> from? At least, it's in the SVN, but the homepage still requires an
> update...)? 

http://download.gna.org/xenomai/documentation/trunk/pdf/

You are right.  It would be nice if the www.xenomai.org documentation links pointed to download.gna.org instead of here:

  http://snail.fsffrance.org/www.xenomai.org/documentation/branches/v2.0.x/

...or at least add the gna.org links in addition to what is there now.

-Jeff

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Alexis Berlemont]

Hi,

> >>>I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
> >>>don't know the current status.
> >>
> >>Indeed. The rumour is called Alex.
> >
> > Yes, I know. I just don't wanted to drag someone to public, saying: "Hey
> > man, already doing your job?" ;)
>
> It's part of the anti-shyness treatment I'm administering to Alex...
>
> > But, as we all know him now, what is the current status then?

My comedi port over RTDM is not completely over (and far from perfect). The 
mmap functionnalities have not been rewritten yet. However, I have been 
working on
-> the port of the comedi infrastructure layer (comedi/comedi_fops.c 
comedi/drivers.c comedi/range.c comedidev.h etc.) 
-> the rewriting of the driver comedi_test.c (which becomes comedi_test1.c)
-> other test stuff has been written in comedi_test2.c (replications functions 
to test comedi_write operations)
-> the ports of comedi_config and comedilib (partially done for comedilib), 
etc.

This stuff is working (minor bugs appart) and I could give you a version in 
the next few days (I have to check "make dist" ;) and minor things).

But there are plenty of things I am not happy with :
-> the original comedilib version is not really well suited for rtdm. In this 
library for many reasons; for example, you can find calls to malloc/free 
functions. If I stick to the original implementation, I have to either to ask 
for adding alloc stuff in user mode in rtdm skin or use another skin to 
manage allocations. None of these solutions seems interesting for me for many 
reasons. A lot of people  must be thinking I am overkill, it is true that the 
comedilib allocations should be done at init time (comedi_open, comedi_close) 
then no need to fulfull real-time constraints but I think comedi should be 
fully rtdm compliant; this would avoid tricky corner cases for 
developpers/users. The best and simplest solution for me would be some slight 
modifications in the comedilib API but I doubt everyone is OK with that.

-> I think the comedi structures organization (comedi_device, subdevice, 
async, etc.) should be reviewed considering the rtdm architecture. Of course, 
these modifications should not induce big changes in the comedi drivers 
source.

-> etc.

In fact, I wanted to propose two versions :
-> a first implementation as close as possible from the original 
implementation and API.
-> a second one a bit more adapted for rtdm.

Thus, we could have compared the two versions and see if everyone agrees with 
the idea of adapting comedi infrastructure. It would have been a good 
opportunity to work closely with comedi developers community.

Unfortunately, my second version is not finished yet. I still have some work 
on it (non negligible). (I know I know I am slower than a turtle which learns 
programming with an amstrad cpc 6128 and damaged floppy disks ). 

If someone is interested in getting a version right now, I will try to send to 
him a tarball as soon as possible. Compared to original comedi deliveries, I 
have not created two autotools tarballs (comedi and comedilib) but only one.

 Regards.

Alexis.

Re: [Xenomai-help] rtdm_event_timedwait hang-up

[Jan Kiszka]

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

Alexis Berlemont wrote:
> Hi,
> 
>>>>> I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
>>>>> don't know the current status.
>>>> Indeed. The rumour is called Alex.
>>> Yes, I know. I just don't wanted to drag someone to public, saying: "Hey
>>> man, already doing your job?" ;)
>> It's part of the anti-shyness treatment I'm administering to Alex...
>>
>>> But, as we all know him now, what is the current status then?
> 
> My comedi port over RTDM is not completely over (and far from perfect).

I pushed this thread to xenomai-core as we are leaving the original
topic and are diving into architectural discussions now. Anyone
interested in COMEDI over RTDM is invited to share her/his view on that
list!

Jan


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

[Xenomai-core] COMEDI over RTDM (was: rtdm_event_timedwait hang-up)

[Jan Kiszka]

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

Hi Alexis,

as this discussion starts to become architectural and low-level, I think
we should move it to xenomai-core and give people who are interested a
chance to jump onto it again there.

Alexis Berlemont wrote:
> Hi,
> 
>>>>> I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
>>>>> don't know the current status.
>>>> Indeed. The rumour is called Alex.
>>> Yes, I know. I just don't wanted to drag someone to public, saying: "Hey
>>> man, already doing your job?" ;)
>> It's part of the anti-shyness treatment I'm administering to Alex...
>>
>>> But, as we all know him now, what is the current status then?
> 
> My comedi port over RTDM is not completely over (and far from perfect). The 
> mmap functionnalities have not been rewritten yet. However, I have been 
> working on
> -> the port of the comedi infrastructure layer (comedi/comedi_fops.c 
> comedi/drivers.c comedi/range.c comedidev.h etc.) 
> -> the rewriting of the driver comedi_test.c (which becomes comedi_test1.c)
> -> other test stuff has been written in comedi_test2.c (replications functions 
> to test comedi_write operations)
> -> the ports of comedi_config and comedilib (partially done for comedilib), 
> etc.
> 
> This stuff is working (minor bugs appart) and I could give you a version in 
> the next few days (I have to check "make dist" ;) and minor things).
> 
> But there are plenty of things I am not happy with :
> -> the original comedilib version is not really well suited for rtdm. In this 
> library for many reasons; for example, you can find calls to malloc/free 

Oops, not so nice.

> functions. If I stick to the original implementation, I have to either to ask 
> for adding alloc stuff in user mode in rtdm skin or use another skin to 
> manage allocations. None of these solutions seems interesting for me for many 
> reasons. A lot of people  must be thinking I am overkill, it is true that the 
> comedilib allocations should be done at init time (comedi_open, comedi_close) 
> then no need to fulfull real-time constraints but I think comedi should be 
> fully rtdm compliant; this would avoid tricky corner cases for 
> developpers/users. The best and simplest solution for me would be some slight 
> modifications in the comedilib API but I doubt everyone is OK with that.

Could you give some concrete use cases of the comedilib where dynamic
allocation is involved? I don't know that library actually. What does it
manage beyond calling the driver core?

> 
> -> I think the comedi structures organization (comedi_device, subdevice, 
> async, etc.) should be reviewed considering the rtdm architecture. Of course, 
> these modifications should not induce big changes in the comedi drivers 
> source.

Please also give concrete examples here. RTDM devices should be
manageable by the user via file descriptors, just like normal devices.
What is different, what extra information is needed?

> 
> -> etc.
> 
> In fact, I wanted to propose two versions :
> -> a first implementation as close as possible from the original 
> implementation and API.
> -> a second one a bit more adapted for rtdm.

What would be different with RTDM compared to the existing RTLinux and
RTAI support of comedi? Don't they use comedilib at all? Isn't there
some LXRT adoption in RTAI? Is it providing a different API?

> 
> Thus, we could have compared the two versions and see if everyone agrees with 
> the idea of adapting comedi infrastructure. It would have been a good 
> opportunity to work closely with comedi developers community.

Yes, that would be best. But I guess it will not be too easy, as there
seems to exist a limited interest in RT on their side. Maybe it just
takes some (more) users explaining the requirements and the need. ;)

> 
> Unfortunately, my second version is not finished yet. I still have some work 
> on it (non negligible). (I know I know I am slower than a turtle which learns 
> programming with an amstrad cpc 6128 and damaged floppy disks ). 
> 
> If someone is interested in getting a version right now, I will try to send to 
> him a tarball as soon as possible. Compared to original comedi deliveries, I 
> have not created two autotools tarballs (comedi and comedilib) but only one.

Release early, release often ;). I would offer to have a look, maybe it
will clarify where the RTDM-specific problems are.

Jan


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

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

[Petr Cervenka]

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. I still have same problems with porting the driver, but I think I can handle them myself.
Thanks for your help.
Petr Cervenka

>  Petr Cervenka wrote:
> > I' tried to create  user realtime task, and after all effort (and
> > many related partial problems solved) I still cannot do blocking
> > variant of rtdm_event_timedwait.
> > 1) How can I recognize, that the function is called within proper
> > context / ie. is there an rtdm equivalent to xnpod_unblockable_p?
> 
> First of all, there is the concept of the dual entry points, one for RT
> (xxx_rt), the other for non-RT (xxx_nrt). If your driver only registers
> a handler on xxx_rt, it will never get called in unblockable context. If
> it registers different functions on those entry points, it can easily
> tell the contexts apart.
> 
> Given that you have some significant amount of code to share between a
> RT and a non-RT invocation, you can register the same handler on both
> entry points. Then rtdm_in_rt_context() will tell you in which context
> you currently are.
> 
> > 2) Could be the problem elsewhere?
> 
> I prepared the attached patch that catches illegal service
> invocations. It will get checked in as soon as we decided how to switch
> XENO_ASSERTs on. For now this is done via CONFIG_XENO_OPT_DEBUG. Feel
> free to apply it on your Xenomai code and check if it's useful. I tested
> it a bit, and it didn't break anything of RTDM in an obvious way. :)
> 
> > 3) My General Standards PCI-24DSI-12 card is not supported by comedi.
> > And I'm not familiar with it either. The original driver is not so
> > complicated and the port looked as easy work ;-) But waiting inside
> 
> I can understand that you do not want to complicate your job with comedi
> when there is no support for your hardware anyway.
> 
> > ioctl or read handler for an interrupt is critical for proper
> > functionality.
> 
> This must work. See the 16550A driver e.g., it has a similar design,
> specifically for handling RTSER_RTIOC_WAIT_EVENT.
> 
> > 4) I realized when I make a realtime task (prio 1 ~ lowest, I hope)
> > and in my main (nrt) task I call sleep(1), It will fall asleep
> > forever (or maybe to some signal).
> 
> Sounds like something is blocking the Linux timer. Did you accidentally
> register your driver on it? See /proc/interrupts for the timer IRQ
> counter, in contrast to /proc/xenomai/irq.
> 
> > 5) Is it possible to set some event or to send signal/message/...
> > from rt to nrt and back?
> 
> rt->nrt: rtdm_nrtsig_xxx
> nrt->rt: any blocking rtdm-IPC service (except for mutexes of course)
> can be signalled also from non-rt
> 
> > 6) Is there some easy-to-understand documentation? What I can or
> > cannot...?
> 
> Did you browse the API documentation of RTDM, maybe also had a look at
> the related RTDM-and-Applications.pdf (hmm, were does a user get this
> from? At least, it's in the SVN, but the homepage still requires an
> update...)? If yes, please let us know what remains unclear and what
> would be additionally desirable. A tour on RTDM, like Philippe already
> wrote for other subsystems, would be nice - it just takes someone to
> write it...
> 
> > Petr Cervenka
> > 
> 
> Jan
> 
> Index: include/rtdm/rtdm_driver.h
> ===================================================================
> --- include/rtdm/.svn/text-base/rtdm_driver.h.svn-base	2006-03-09
> 22:16:03.000000000 +0100
> +++ include/rtdm/rtdm_driver.h	2006-03-20 17:55:10.000000000 +0100
> @@ -38,6 +38,7 @@
>  #include <nucleus>
>  #include <nucleus>
>  #include <nucleus>
> +#include <nucleus>
>  #include <rtdm>
>  
>  
> @@ -890,6 +891,7 @@ static inline rtdm_task_t *rtdm_task_cur
>  
>  static inline int rtdm_task_wait_period(void)
>  {
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>      return xnpod_wait_thread_period(NULL);
>  }
>  
> Index: include/nucleus/assert.h
> ===================================================================
> --- include/nucleus/.svn/text-base/assert.h.svn-base	2006-03-08
> 00:48:14.000000000 +0100
> +++ include/nucleus/assert.h	2006-03-20 20:04:10.000000000 +0100
> @@ -22,18 +22,14 @@
>  
>  #include <nucleus>
>  
> -#ifndef CONFIG_XENO_OPT_DEBUG_LEVEL
> -#define CONFIG_XENO_OPT_DEBUG_LEVEL  0
> -#endif
> -
> -#if CONFIG_XENO_OPT_DEBUG_LEVEL > 0
> +#if CONFIG_XENO_OPT_DEBUG
>  #define XENO_ASSERT(cond,action)  do { \
>  if (unlikely((cond) != 0)) \
>  	do { action; } while(0); \
>  } while(0)
> -#else  /* CONFIG_XENO_OPT_DEBUG_LEVEL == 0 */
> +#else  /* !CONFIG_XENO_OPT_DEBUG */
>  #define XENO_ASSERT(cond,action) do { } while(0)
> -#endif /* CONFIG_XENO_OPT_DEBUG_LEVEL > 0 */
> +#endif /* CONFIG_XENO_OPT_DEBUG */
>  
>  #define XENO_BUGON(cond)  \
>      XENO_ASSERT(cond,xnpod_fatal("assertion failed at
> %s:%d",__FILE__,__LINE__))
> Index: ksrc/skins/rtdm/drvlib.c
> ===================================================================
> --- ksrc/skins/rtdm/.svn/text-base/drvlib.c.svn-base	2006-03-13
> 23:13:19.000000000 +0100
> +++ ksrc/skins/rtdm/drvlib.c	2006-03-20 20:11:38.000000000 +0100
> @@ -279,6 +279,8 @@ void rtdm_task_join_nrt(rtdm_task_t *tas
>      spl_t s;
>  
>  
> +    XENO_ASSERT(xnpod_root_p(), return;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      while (!xnthread_test_flags(task, XNZOMBIE)) {
> @@ -305,6 +307,9 @@ EXPORT_SYMBOL(rtdm_task_join_nrt);
>   * - -EINTR is returned if calling task has been unblock by a signal or
>   * explicitely via rtdm_task_unblock().
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -319,6 +324,8 @@ int rtdm_task_sleep(uint64_t delay)
>      xnthread_t  *thread = xnpod_current_thread();
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnpod_suspend_thread(thread, XNDELAY, xnpod_ns2ticks(delay), NULL);
>  
>      return xnthread_test_flags(thread, XNBREAK) ? -EINTR : 0;
> @@ -337,6 +344,9 @@ EXPORT_SYMBOL(rtdm_task_sleep);
>   * - -EINTR is returned if calling task has been unblock by a signal or
>   * explicitely via rtdm_task_unblock().
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -354,6 +364,8 @@ int rtdm_task_sleep_until(uint64_t wakeu
>      int         err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      delay = xnpod_ns2ticks(wakeup_time) - xnpod_get_time();
> @@ -626,6 +638,9 @@ EXPORT_SYMBOL(rtdm_event_signal);
>   *
>   * - -EIDRM is returned if @a event has been destroyed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -641,6 +656,8 @@ int rtdm_event_wait(rtdm_event_t *event)
>      int     err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      if (testbits(event->synch_base.status, SYNCH_DELETED))
> @@ -689,6 +706,9 @@ EXPORT_SYMBOL(rtdm_event_wait);
>   *
>   * - -EIDRM is returned if @a event has been destroyed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -706,6 +726,8 @@ int rtdm_event_timedwait(rtdm_event_t *e
>      int         err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      if (unlikely(testbits(event->synch_base.status, SYNCH_DELETED)))
> @@ -810,6 +832,9 @@ void rtdm_sem_destroy(rtdm_sem_t *sem);
>   *
>   * - -EIDRM is returned if @a sem has been destroyed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -825,6 +850,8 @@ int rtdm_sem_down(rtdm_sem_t *sem)
>      int     err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      if (testbits(sem->synch_base.status, SYNCH_DELETED))
> @@ -878,6 +905,9 @@ EXPORT_SYMBOL(rtdm_sem_down);
>   *
>   * - -EIDRM is returned if @a sem has been destroyed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -895,6 +925,8 @@ int rtdm_sem_timeddown(rtdm_sem_t *sem, 
>      int         err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      if (testbits(sem->synch_base.status, SYNCH_DELETED))
> @@ -1035,6 +1067,9 @@ void rtdm_mutex_destroy(rtdm_mutex_t *mu
>   *
>   * - -EIDRM is returned if @a mutex has been destroyed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -1050,6 +1085,8 @@ int rtdm_mutex_lock(rtdm_mutex_t *mutex)
>      int     err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      if (testbits(mutex->synch_base.status, SYNCH_DELETED))
> @@ -1097,6 +1134,9 @@ EXPORT_SYMBOL(rtdm_mutex_lock);
>   *
>   * - -EIDRM is returned if @a mutex has been destroyed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -1114,6 +1154,8 @@ int rtdm_mutex_timedlock(rtdm_mutex_t *m
>      int         err = 0;
>  
>  
> +    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      if (testbits(mutex->synch_base.status, SYNCH_DELETED))
> @@ -1179,6 +1221,8 @@ void rtdm_mutex_unlock(rtdm_mutex_t *mut
>      spl_t s;
>  
>  
> +    XENO_ASSERT(!xnpod_asynch_p(), return;);
> +
>      xnlock_get_irqsave(&nklock, s);
>  
>      __clear_bit(0, &mutex->locked);
> @@ -1426,6 +1470,9 @@ static struct file_operations rtdm_mmap_
>   * - -EAGAIN is returned if too much memory has been already locked by
> the
>   * user process.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * @note RTDM supports two models for unmapping the user memory range
> again.
>   * One is explicite unmapping via rtdm_munmap(), either performed when
> the
>   * user requests it via an IOCTL etc. or when the related device is
> closed.
> @@ -1457,6 +1504,9 @@ int rtdm_mmap_to_user(rtdm_user_info_t *
>      void                    *old_priv_data;
>      void                    *user_ptr;
>  
> +
> +    XENO_ASSERT(xnpod_root_p(), return -EPERM;);
> +
>      filp = filp_open("/dev/zero", O_RDWR, 0);
>      if (IS_ERR(filp))
>          return PTR_ERR(filp);
> @@ -1499,6 +1549,9 @@ EXPORT_SYMBOL(rtdm_mmap_to_user);
>   *
>   * - -EINVAL is returned if an invalid address or size was passed.
>   *
> + * - -EPERM @e may be returned if an illegal invocation environment is
> + * detected.
> + *
>   * Environments:
>   *
>   * This service can be called from:
> @@ -1512,6 +1565,9 @@ int rtdm_munmap(rtdm_user_info_t *user_i
>  {
>      int err;
>  
> +
> +    XENO_ASSERT(xnpod_root_p(), return -EPERM;);
> +
>      down_write(&user_info->mm->mmap_sem);
>      err = do_munmap(user_info->mm, (unsigned long)ptr, len);
>      up_write(&user_info->mm->mmap_sem);
> 
> </nucleus></rtdm></nucleus></nucleus></nucleus></nucleus>

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

[Philippe Gerum]

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.

Well, actually, it shouldn't be necessary for your task to manage this 
mode by hand. The skin _syscall_ should do it transparently for you as 
needed.

  I still have same problems with porting the driver, but I think I can 
handle them myself.
> Thanks for your help.
> Petr Cervenka
> 
> 
>> Petr Cervenka wrote:
>>
>>>I' tried to create  user realtime task, and after all effort (and
>>>many related partial problems solved) I still cannot do blocking
>>>variant of rtdm_event_timedwait.
>>>1) How can I recognize, that the function is called within proper
>>>context / ie. is there an rtdm equivalent to xnpod_unblockable_p?
>>
>>First of all, there is the concept of the dual entry points, one for RT
>>(xxx_rt), the other for non-RT (xxx_nrt). If your driver only registers
>>a handler on xxx_rt, it will never get called in unblockable context. If
>>it registers different functions on those entry points, it can easily
>>tell the contexts apart.
>>
>>Given that you have some significant amount of code to share between a
>>RT and a non-RT invocation, you can register the same handler on both
>>entry points. Then rtdm_in_rt_context() will tell you in which context
>>you currently are.
>>
>>
>>>2) Could be the problem elsewhere?
>>
>>I prepared the attached patch that catches illegal service
>>invocations. It will get checked in as soon as we decided how to switch
>>XENO_ASSERTs on. For now this is done via CONFIG_XENO_OPT_DEBUG. Feel
>>free to apply it on your Xenomai code and check if it's useful. I tested
>>it a bit, and it didn't break anything of RTDM in an obvious way. :)
>>
>>
>>>3) My General Standards PCI-24DSI-12 card is not supported by comedi.
>>>And I'm not familiar with it either. The original driver is not so
>>>complicated and the port looked as easy work ;-) But waiting inside
>>
>>I can understand that you do not want to complicate your job with comedi
>>when there is no support for your hardware anyway.
>>
>>
>>>ioctl or read handler for an interrupt is critical for proper
>>>functionality.
>>
>>This must work. See the 16550A driver e.g., it has a similar design,
>>specifically for handling RTSER_RTIOC_WAIT_EVENT.
>>
>>
>>>4) I realized when I make a realtime task (prio 1 ~ lowest, I hope)
>>>and in my main (nrt) task I call sleep(1), It will fall asleep
>>>forever (or maybe to some signal).
>>
>>Sounds like something is blocking the Linux timer. Did you accidentally
>>register your driver on it? See /proc/interrupts for the timer IRQ
>>counter, in contrast to /proc/xenomai/irq.
>>
>>
>>>5) Is it possible to set some event or to send signal/message/...
>>>from rt to nrt and back?
>>
>>rt->nrt: rtdm_nrtsig_xxx
>>nrt->rt: any blocking rtdm-IPC service (except for mutexes of course)
>>can be signalled also from non-rt
>>
>>
>>>6) Is there some easy-to-understand documentation? What I can or
>>>cannot...?
>>
>>Did you browse the API documentation of RTDM, maybe also had a look at
>>the related RTDM-and-Applications.pdf (hmm, were does a user get this
>>from? At least, it's in the SVN, but the homepage still requires an
>>update...)? If yes, please let us know what remains unclear and what
>>would be additionally desirable. A tour on RTDM, like Philippe already
>>wrote for other subsystems, would be nice - it just takes someone to
>>write it...
>>
>>
>>>Petr Cervenka
>>>
>>
>>Jan
>>
>>Index: include/rtdm/rtdm_driver.h
>>===================================================================
>>--- include/rtdm/.svn/text-base/rtdm_driver.h.svn-base	2006-03-09
>>22:16:03.000000000 +0100
>>+++ include/rtdm/rtdm_driver.h	2006-03-20 17:55:10.000000000 +0100
>>@@ -38,6 +38,7 @@
>> #include <nucleus>
>> #include <nucleus>
>> #include <nucleus>
>>+#include <nucleus>
>> #include <rtdm>
>> 
>> 
>>@@ -890,6 +891,7 @@ static inline rtdm_task_t *rtdm_task_cur
>> 
>> static inline int rtdm_task_wait_period(void)
>> {
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>     return xnpod_wait_thread_period(NULL);
>> }
>> 
>>Index: include/nucleus/assert.h
>>===================================================================
>>--- include/nucleus/.svn/text-base/assert.h.svn-base	2006-03-08
>>00:48:14.000000000 +0100
>>+++ include/nucleus/assert.h	2006-03-20 20:04:10.000000000 +0100
>>@@ -22,18 +22,14 @@
>> 
>> #include <nucleus>
>> 
>>-#ifndef CONFIG_XENO_OPT_DEBUG_LEVEL
>>-#define CONFIG_XENO_OPT_DEBUG_LEVEL  0
>>-#endif
>>-
>>-#if CONFIG_XENO_OPT_DEBUG_LEVEL > 0
>>+#if CONFIG_XENO_OPT_DEBUG
>> #define XENO_ASSERT(cond,action)  do { \
>> if (unlikely((cond) != 0)) \
>> 	do { action; } while(0); \
>> } while(0)
>>-#else  /* CONFIG_XENO_OPT_DEBUG_LEVEL == 0 */
>>+#else  /* !CONFIG_XENO_OPT_DEBUG */
>> #define XENO_ASSERT(cond,action) do { } while(0)
>>-#endif /* CONFIG_XENO_OPT_DEBUG_LEVEL > 0 */
>>+#endif /* CONFIG_XENO_OPT_DEBUG */
>> 
>> #define XENO_BUGON(cond)  \
>>     XENO_ASSERT(cond,xnpod_fatal("assertion failed at
>>%s:%d",__FILE__,__LINE__))
>>Index: ksrc/skins/rtdm/drvlib.c
>>===================================================================
>>--- ksrc/skins/rtdm/.svn/text-base/drvlib.c.svn-base	2006-03-13
>>23:13:19.000000000 +0100
>>+++ ksrc/skins/rtdm/drvlib.c	2006-03-20 20:11:38.000000000 +0100
>>@@ -279,6 +279,8 @@ void rtdm_task_join_nrt(rtdm_task_t *tas
>>     spl_t s;
>> 
>> 
>>+    XENO_ASSERT(xnpod_root_p(), return;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     while (!xnthread_test_flags(task, XNZOMBIE)) {
>>@@ -305,6 +307,9 @@ EXPORT_SYMBOL(rtdm_task_join_nrt);
>>  * - -EINTR is returned if calling task has been unblock by a signal or
>>  * explicitely via rtdm_task_unblock().
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -319,6 +324,8 @@ int rtdm_task_sleep(uint64_t delay)
>>     xnthread_t  *thread = xnpod_current_thread();
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnpod_suspend_thread(thread, XNDELAY, xnpod_ns2ticks(delay), NULL);
>> 
>>     return xnthread_test_flags(thread, XNBREAK) ? -EINTR : 0;
>>@@ -337,6 +344,9 @@ EXPORT_SYMBOL(rtdm_task_sleep);
>>  * - -EINTR is returned if calling task has been unblock by a signal or
>>  * explicitely via rtdm_task_unblock().
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -354,6 +364,8 @@ int rtdm_task_sleep_until(uint64_t wakeu
>>     int         err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     delay = xnpod_ns2ticks(wakeup_time) - xnpod_get_time();
>>@@ -626,6 +638,9 @@ EXPORT_SYMBOL(rtdm_event_signal);
>>  *
>>  * - -EIDRM is returned if @a event has been destroyed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -641,6 +656,8 @@ int rtdm_event_wait(rtdm_event_t *event)
>>     int     err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     if (testbits(event->synch_base.status, SYNCH_DELETED))
>>@@ -689,6 +706,9 @@ EXPORT_SYMBOL(rtdm_event_wait);
>>  *
>>  * - -EIDRM is returned if @a event has been destroyed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -706,6 +726,8 @@ int rtdm_event_timedwait(rtdm_event_t *e
>>     int         err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     if (unlikely(testbits(event->synch_base.status, SYNCH_DELETED)))
>>@@ -810,6 +832,9 @@ void rtdm_sem_destroy(rtdm_sem_t *sem);
>>  *
>>  * - -EIDRM is returned if @a sem has been destroyed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -825,6 +850,8 @@ int rtdm_sem_down(rtdm_sem_t *sem)
>>     int     err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     if (testbits(sem->synch_base.status, SYNCH_DELETED))
>>@@ -878,6 +905,9 @@ EXPORT_SYMBOL(rtdm_sem_down);
>>  *
>>  * - -EIDRM is returned if @a sem has been destroyed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -895,6 +925,8 @@ int rtdm_sem_timeddown(rtdm_sem_t *sem, 
>>     int         err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     if (testbits(sem->synch_base.status, SYNCH_DELETED))
>>@@ -1035,6 +1067,9 @@ void rtdm_mutex_destroy(rtdm_mutex_t *mu
>>  *
>>  * - -EIDRM is returned if @a mutex has been destroyed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -1050,6 +1085,8 @@ int rtdm_mutex_lock(rtdm_mutex_t *mutex)
>>     int     err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     if (testbits(mutex->synch_base.status, SYNCH_DELETED))
>>@@ -1097,6 +1134,9 @@ EXPORT_SYMBOL(rtdm_mutex_lock);
>>  *
>>  * - -EIDRM is returned if @a mutex has been destroyed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -1114,6 +1154,8 @@ int rtdm_mutex_timedlock(rtdm_mutex_t *m
>>     int         err = 0;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_unblockable_p(), return -EPERM;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     if (testbits(mutex->synch_base.status, SYNCH_DELETED))
>>@@ -1179,6 +1221,8 @@ void rtdm_mutex_unlock(rtdm_mutex_t *mut
>>     spl_t s;
>> 
>> 
>>+    XENO_ASSERT(!xnpod_asynch_p(), return;);
>>+
>>     xnlock_get_irqsave(&nklock, s);
>> 
>>     __clear_bit(0, &mutex->locked);
>>@@ -1426,6 +1470,9 @@ static struct file_operations rtdm_mmap_
>>  * - -EAGAIN is returned if too much memory has been already locked by
>>the
>>  * user process.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * @note RTDM supports two models for unmapping the user memory range
>>again.
>>  * One is explicite unmapping via rtdm_munmap(), either performed when
>>the
>>  * user requests it via an IOCTL etc. or when the related device is
>>closed.
>>@@ -1457,6 +1504,9 @@ int rtdm_mmap_to_user(rtdm_user_info_t *
>>     void                    *old_priv_data;
>>     void                    *user_ptr;
>> 
>>+
>>+    XENO_ASSERT(xnpod_root_p(), return -EPERM;);
>>+
>>     filp = filp_open("/dev/zero", O_RDWR, 0);
>>     if (IS_ERR(filp))
>>         return PTR_ERR(filp);
>>@@ -1499,6 +1549,9 @@ EXPORT_SYMBOL(rtdm_mmap_to_user);
>>  *
>>  * - -EINVAL is returned if an invalid address or size was passed.
>>  *
>>+ * - -EPERM @e may be returned if an illegal invocation environment is
>>+ * detected.
>>+ *
>>  * Environments:
>>  *
>>  * This service can be called from:
>>@@ -1512,6 +1565,9 @@ int rtdm_munmap(rtdm_user_info_t *user_i
>> {
>>     int err;
>> 
>>+
>>+    XENO_ASSERT(xnpod_root_p(), return -EPERM;);
>>+
>>     down_write(&user_info->mm->mmap_sem);
>>     err = do_munmap(user_info->mm, (unsigned long)ptr, len);
>>     up_write(&user_info->mm->mmap_sem);
>>
>></nucleus></rtdm></nucleus></nucleus></nucleus></nucleus>
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

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

[Jan Kiszka]

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

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. 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


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

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

[Philippe Gerum]

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
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.

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

[Jan Kiszka]

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

Philippe Gerum wrote:
> 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?

Its the difference between a RT thread issuing some service request
during its init phase (where it may not need hard guarantees, rather
wants to save short RT resources) and from inside its critical loop
(where no mode switch is desired). The second case would be ok with
"default-to-RT", but the first one would require to move the job into a
plain linux thread in order to address the _nrt variant of the invoked
service.

A concrete example: RTnet can create sockets with strict RT guarantees.
In case the socket creation is invoked from primary mode, the required
buffers for the socket are taken from a limited, user-tuned global pool.
But the standard, far more convenient case is that socket creation does
not have to happen in RT. In this case we can allocate the buffers from
Linux. This may lead to swapping or may even fail if the system is
generally low on memory. But that's non-RT. An RT task can now select
the allocation strategy by setting its execution mode either to primary
or secondary.

Selecting the strategy via function arguments may appear as a better
way, but this cannot easily be done where conformance to existing APIs
(like POSIX) is desired.

Jan


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

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

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>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?
> 
> 
> Its the difference between a RT thread issuing some service request
> during its init phase (where it may not need hard guarantees, rather
> wants to save short RT resources) and from inside its critical loop
> (where no mode switch is desired). The second case would be ok with
> "default-to-RT", but the first one would require to move the job into a
> plain linux thread in order to address the _nrt variant of the invoked
> service.
> 
> A concrete example: RTnet can create sockets with strict RT guarantees.
> In case the socket creation is invoked from primary mode, the required
> buffers for the socket are taken from a limited, user-tuned global pool.
> But the standard, far more convenient case is that socket creation does
> not have to happen in RT. In this case we can allocate the buffers from
> Linux. This may lead to swapping or may even fail if the system is
> generally low on memory. But that's non-RT. An RT task can now select
> the allocation strategy by setting its execution mode either to primary
> or secondary.
> 
> Selecting the strategy via function arguments may appear as a better
> way, but this cannot easily be done where conformance to existing APIs
> (like POSIX) is desired.

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.

-- 

Philippe.

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

[Jan Kiszka]

[-- 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 --]

[Xenomai-core] Re: COMEDI over RTDM (was: rtdm_event_timedwait hang-up)

[Alexis Berlemont]

Hi,

> > But there are plenty of things I am not happy with :
> > -> the original comedilib version is not really well suited for rtdm. In
> > this library for many reasons; for example, you can find calls to
> > malloc/free
>
> Oops, not so nice.
>
> > functions. If I stick to the original implementation, I have to either to
> > ask for adding alloc stuff in user mode in rtdm skin or use another skin
> > to manage allocations. None of these solutions seems interesting for me
> > for many reasons. A lot of people  must be thinking I am overkill, it is
> > true that the comedilib allocations should be done at init time
> > (comedi_open, comedi_close) then no need to fulfull real-time constraints
> > but I think comedi should be fully rtdm compliant; this would avoid
> > tricky corner cases for
> > developpers/users. The best and simplest solution for me would be some
> > slight modifications in the comedilib API but I doubt everyone is OK with
> > that.
>
> Could you give some concrete use cases of the comedilib where dynamic
> allocation is involved? I don't know that library actually. What does it
> manage beyond calling the driver core?

In the function comedi_open() : 

  if(!(it=malloc(sizeof(comedi_t))))
    goto cleanup;
  memset(it,0,sizeof(comedi_t));

  if((it->fd=rt_dev_open(fn,0))<0)
  {
    fprintf(stderr, "comedi_open: rt_dev_open failed (ret=%d)\n",
	    it->fd);
    goto cleanup;
  }

  if(comedi_ioctl(it->fd, COMEDI_DEVINFO, 
		  (unsigned long)&it->devinfo)<0)
    goto cleanup;

  it->n_subdevices=it->devinfo.n_subdevs;

  get_subdevices(it);

...

We can see an allocation for a structure which will contain the result ("fd") 
of rt_dev_open(). And this is not over, the function "get_subdevices()" will 
make another allocation to keep info about the driver (subdevice, number of 
channels, etc.). And this function "get_subdevices()" will trigger more 
allocations by calling "get_rangeinfo()". In fact, "malloc()" is called eight 
times.

All disallocations are done in "comedi_close()".

Starting from here, we have two alternatives:
-> preallocate enough structs the first time "comedi_open()" is called. mmh...
-> modify the comedilib API to let the developper handle the allocations.

> > -> I think the comedi structures organization (comedi_device, subdevice,
> > async, etc.) should be reviewed considering the rtdm architecture. Of
> > course, these modifications should not induce big changes in the comedi
> > drivers source.
>
> Please also give concrete examples here. RTDM devices should be
> manageable by the user via file descriptors, just like normal devices.

There is a little difference with normal devices and classical drivers. The 
link between a device and a driver is not direct. The comedi layer affects a 
comedi device (/dev/comedi0..9 or comedi0..9) to a specific driver at runtime 
thanks to a specific ioctl (cf. comedi_config in comedilib). This is the 
comedi attach stuff.

At this level, I may think it would be interesting to consider quite precisely 
the layer organization. I have not well understood the architectural border 
between what must be done by the driver and what must be done by the abstract 
layer.

For example, here is a description of the attaching procedure: 
1) the devconfig ioctl is received by the abstract comedi layer;
2) the abstract layer (in comedi/drivers.c) calls do_devconfig_ioctl() which 
makes some allocations and a few setups in the structure comedi_device, the 
the function comedi_device_attach() is called;
3)In comedi_device_attach(), we check if the proper driver whether available 
(insmoded), if so a driver specific function is called;
4) in this driver function, we have access to the structures of the abstract 
layer and we modify them (comedi_subdevice);
5) back in the abstract layer, the function "postconfig() is called to setup 
the struct "comedi_async" (this struct belongs to a comedi_subdevice).

To sum up: 
-> comedi_device { (managed by the abstract layer)
	-> comedi_subdevice { (managed by the driver)
		-> comedi_async (managed by the abstract layer)
	}
}

I am not sure I am clear (it is quite hard to explain without source code), 
but I think the drivers should not get direct access to the structures of the 
abstract layer. 

You may find this points useless, all this stuff is not directly related with 
rtdm functionnalities, I just thought the rtdm port would be a good 
opportunity to think about that. 

> What is different, what extra information is needed?

. I just think some fields could be removed or grouped in comedi_subdevice 
(lock, busy, etc.) and we could integrate in comedi_async the nonblocking 
info. This is minor.

I may have some more points to share with you but I have to keep them for 
tomorrow night.

> Release early, release often ;). I would offer to have a look, maybe it
> will clarify where the RTDM-specific problems are.

OK sorry for tonight, hard day...

Alexis.

[Xenomai-core] Re: COMEDI over RTDM

[Jan Kiszka]

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

Alexis Berlemont wrote:
> Hi,
> 
>>> But there are plenty of things I am not happy with :
>>> -> the original comedilib version is not really well suited for rtdm. In
>>> this library for many reasons; for example, you can find calls to
>>> malloc/free
>> Oops, not so nice.
>>
>>> functions. If I stick to the original implementation, I have to either to
>>> ask for adding alloc stuff in user mode in rtdm skin or use another skin
>>> to manage allocations. None of these solutions seems interesting for me
>>> for many reasons. A lot of people  must be thinking I am overkill, it is
>>> true that the comedilib allocations should be done at init time
>>> (comedi_open, comedi_close) then no need to fulfull real-time constraints
>>> but I think comedi should be fully rtdm compliant; this would avoid
>>> tricky corner cases for
>>> developpers/users. The best and simplest solution for me would be some
>>> slight modifications in the comedilib API but I doubt everyone is OK with
>>> that.
>> Could you give some concrete use cases of the comedilib where dynamic
>> allocation is involved? I don't know that library actually. What does it
>> manage beyond calling the driver core?
> 
> In the function comedi_open() : 
> 
>   if(!(it=malloc(sizeof(comedi_t))))
>     goto cleanup;
>   memset(it,0,sizeof(comedi_t));
> 
>   if((it->fd=rt_dev_open(fn,0))<0)
>   {
>     fprintf(stderr, "comedi_open: rt_dev_open failed (ret=%d)\n",
> 	    it->fd);
>     goto cleanup;
>   }
> 
>   if(comedi_ioctl(it->fd, COMEDI_DEVINFO, 
> 		  (unsigned long)&it->devinfo)<0)
>     goto cleanup;
> 
>   it->n_subdevices=it->devinfo.n_subdevs;
> 
>   get_subdevices(it);
> 
> ...
> 
> We can see an allocation for a structure which will contain the result ("fd") 
> of rt_dev_open(). And this is not over, the function "get_subdevices()" will 
> make another allocation to keep info about the driver (subdevice, number of 
> channels, etc.). And this function "get_subdevices()" will trigger more 
> allocations by calling "get_rangeinfo()". In fact, "malloc()" is called eight 
> times.
> 
> All disallocations are done in "comedi_close()".

Ok, then opening and closing comedi devices is not deterministic and
must not happen when strict timing requirements exist - but that's a
rather unlikely scenario anyway. As long as there is no
allocation/release in the acquisition code path...

> 
> Starting from here, we have two alternatives:
> -> preallocate enough structs the first time "comedi_open()" is called. mmh...
> -> modify the comedilib API to let the developper handle the allocations.
> 
>>> -> I think the comedi structures organization (comedi_device, subdevice,
>>> async, etc.) should be reviewed considering the rtdm architecture. Of
>>> course, these modifications should not induce big changes in the comedi
>>> drivers source.
>> Please also give concrete examples here. RTDM devices should be
>> manageable by the user via file descriptors, just like normal devices.
> 
> There is a little difference with normal devices and classical drivers. The 
> link between a device and a driver is not direct. The comedi layer affects a 
> comedi device (/dev/comedi0..9 or comedi0..9) to a specific driver at runtime 
> thanks to a specific ioctl (cf. comedi_config in comedilib). This is the 
> comedi attach stuff.

Then what does comedi0..9 stand for, some interface channel?

> 
> At this level, I may think it would be interesting to consider quite precisely 
> the layer organization. I have not well understood the architectural border 
> between what must be done by the driver and what must be done by the abstract 
> layer.
> 
> For example, here is a description of the attaching procedure: 
> 1) the devconfig ioctl is received by the abstract comedi layer;
> 2) the abstract layer (in comedi/drivers.c) calls do_devconfig_ioctl() which 
> makes some allocations and a few setups in the structure comedi_device, the 
> the function comedi_device_attach() is called;
> 3)In comedi_device_attach(), we check if the proper driver whether available 
> (insmoded), if so a driver specific function is called;
> 4) in this driver function, we have access to the structures of the abstract 
> layer and we modify them (comedi_subdevice);
> 5) back in the abstract layer, the function "postconfig() is called to setup 
> the struct "comedi_async" (this struct belongs to a comedi_subdevice).
> 
> To sum up: 
> -> comedi_device { (managed by the abstract layer)
> 	-> comedi_subdevice { (managed by the driver)
> 		-> comedi_async (managed by the abstract layer)
> 	}
> }
> 
> I am not sure I am clear (it is quite hard to explain without source code), 
> but I think the drivers should not get direct access to the structures of the 
> abstract layer. 
> 
> You may find this points useless, all this stuff is not directly related with 
> rtdm functionnalities, I just thought the rtdm port would be a good 
> opportunity to think about that. 

Yes, certainly. And as it's not related to real-time or RTDM, this
should definitely raise the interest of the comedi developers as well. I
can only recommend torturing them with questions about why things are
the way they are!

> 
>> What is different, what extra information is needed?
> 
> . I just think some fields could be removed or grouped in comedi_subdevice 
> (lock, busy, etc.) and we could integrate in comedi_async the nonblocking 
> info. This is minor.
> 
> I may have some more points to share with you but I have to keep them for 
> tomorrow night.
> 
>> Release early, release often ;). I would offer to have a look, maybe it
>> will clarify where the RTDM-specific problems are.
> 
> OK sorry for tonight, hard day...
> 
> Alexis.
> 

Jan


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