Re: [Xenomai-help] rtdm_event_timedwait hang-up

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

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