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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
