On Thu, May 12, 2016 at 09:27:43PM +0200, Jan Kiszka wrote: > On 2016-05-12 21:08, Philippe Gerum wrote: > > On 05/12/2016 08:42 PM, Jan Kiszka wrote: > >> On 2016-05-12 20:35, Philippe Gerum wrote: > >>> On 05/12/2016 08:24 PM, Jan Kiszka wrote: > >>>> On 2016-05-12 20:20, Gilles Chanteperdrix wrote: > >>>>> On Thu, May 12, 2016 at 07:17:15PM +0200, Jan Kiszka wrote: > >>>>>> On 2016-05-12 19:12, Gilles Chanteperdrix wrote: > >>>>>>> On Thu, May 12, 2016 at 06:59:04PM +0200, Gilles Chanteperdrix wrote: > >>>>>>>> On Thu, May 12, 2016 at 06:50:03PM +0200, Jan Kiszka wrote: > >>>>>>>>> On 2016-05-12 18:31, Gilles Chanteperdrix wrote: > >>>>>>>>>> On Thu, May 12, 2016 at 06:06:16PM +0200, Jan Kiszka wrote: > >>>>>>>>>>> Gilles, > >>>>>>>>>>> > >>>>>>>>>>> regarding commit bec5d0dd42 (rtdm: make syscalls conforming > >>>>>>>>>>> rather than > >>>>>>>>>>> current) - I remember a discussion on that topic, but I do not > >>>>>>>>>>> find its > >>>>>>>>>>> traces any more. Do you have a pointer > >>>>>>>>>>> > >>>>>>>>>>> In any case, I'm confronted with a use case for the old (Xenomai > >>>>>>>>>>> 2), > >>>>>>>>>>> lazy switching behaviour: lightweight, performance sensitive IOCTL > >>>>>>>>>>> services that can (and should) be called without any switching > >>>>>>>>>>> from both > >>>>>>>>>>> domains. > >>>>>>>>>> > >>>>>>>>>> Why not using a plain linux driver? ioctl_nrt callbacks are > >>>>>>>>>> redundant with plain linux drivers. > >>>>>>>>> > >>>>>>>>> Because that enforces the calling layer to either call the same > >>>>>>>>> service > >>>>>>>>> via a plain Linux device if the calling thread is currently relaxed > >>>>>>>>> or > >>>>>>>>> go for the RT device if the caller is in primary. Doable, but I > >>>>>>>>> would > >>>>>>>>> really like to avoid this pain for the users. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> What were the arguments in favour of migrating threads to > >>>>>>>>>>> real-time first? > >>>>>>>>>>> > >>>>>>>>>>> I currently see the real need only for IOCTLs, but the question > >>>>>>>>>>> is then > >>>>>>>>>>> if we shouldn't go back to "__xn_exec_current" in all RTDM cases > >>>>>>>>>>> to > >>>>>>>>>>> avoid unwanted migration costs (which are significantly higher > >>>>>>>>>>> than > >>>>>>>>>>> syscall restarts). > >>>>>>>>>> > >>>>>>>>>> I do not find commit bec5d0dd42 in xenomai-2.6 git tree, and I do > >>>>>>>>> > >>>>>>>>> Xenomai 2 is still following the lazy scheme - we reverted that > >>>>>>>>> commit > >>>>>>>>> later on in 7df0c1d96b. Xenomai 3 changed it again with the commit > >>>>>>>>> above. > >>>>>>>>> > >>>>>>>>>> not remember merging this. However I find commit > >>>>>>>>>> 13bfdd477ab880499d2e8f3b82c49ef4d2cccff0 from 2010 which seems to > >>>>>>>>>> explain the reason pretty clear. > >>>>>>>>>> > >>>>>>>>>> At the time of the discussion we had concluded that it was the way > >>>>>>>>>> to go. With __xn_exec_current you may enter the ioctl_rt callback > >>>>>>>>>> from secondary domain, which is counter-intuitive, error-prone, and > >>>>>>>>>> forces you to cripple driver code for checks for the current > >>>>>>>>>> domain. > >>>>>>>>> > >>>>>>>>> Nope, normal drivers are not affected as they just implement those > >>>>>>>>> services in the respective mode they want to support there and have > >>>>>>>>> a > >>>>>>>>> simple -ENOSYS for the rest (explicitly in IOCTLs or implicitly by > >>>>>>>>> leaving out the implementation of the counterpart handler). > >>>>>>>> > >>>>>>>> Yes, I got mixed up trying to remember. I think the crux of the > >>>>>>>> problem is that if a thread running in primary mode gets > >>>>>>>> (temporarily) switched to secondary mode by gdb, the ioctl_nrt > >>>>>>>> handler gets invoked, which is almost certainly the wrong thing to > >>>>>>>> do. You want the thread to migrate to primary mode to execute > >>>>>>>> ioctl_rt, which __xn_exec_conforming achieves. Otherwise running an > >>>>>>>> application in gdb causes the application to behave differently. > >>>>>>> > >>>>>>> And trying and avoiding this issue indeed cripple codes with checks > >>>>>>> for rtdm_in_rt_context: > >>>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/analogy/rtdm_interface.c#n194 > >>>>>>> > >>>>>> > >>>>>> I don't remember details here, but this is a special case: The driver > >>>>>> provides also read_nrt - is that really useful for Analogy? > >>>>>> > >>>>>> In most cases, you are fine with not providing the nrt (or rt) handler, > >>>>>> or with a simple > >>>>>> > >>>>>> default: > >>>>>> return -ENOSYS; > >>>>>> > >>>>>> in your ioctl dispatcher. > >>>>> > >>>>> You are missing the point: if you enter read_nrt, there are two > >>>>> cases: > >>>>> - either the thread is real-time capable and has been relaxed by gdb > >>>>> and you want to switch to read_rt for the reasons I already > >>>>> explained, in that case, you must return -ENOSYS; > >>>>> - or the thread is not real-time capable and the nrt handler > >>>>> applies. > >>>>> > >>>>> So, you need at least > >>>>> > >>>>> read_nrt() > >>>>> { > >>>>> if (rt_capable) > >>>>> return -ENOSYS; > >>>>> > >>>>> /* Do the normal case here */ > >>>>> } > >>>> > >>>> Now tell me how many drivers have read_nrt, write_nrt? 1 in-tree. > >>>> recvmsg_nrt, sendmsg_nrt? 0 in-tree. Analogy is special (still like to > >>>> understand why, though). And having some special code in the exceptional > >>>> case is probably better then the side effects we get from eagerly > >>>> switching now. > >>>> > >>> > >>> Sorry, that is exactly the opposite: your use case is exceptional and I > >>> believe is wrong. The normal use case is the one that does not ask the > >>> user to track the current mode for knowing what any random driver would > >>> eventually do depending on the calling context. > >> > >> You still miss the point that this is not required in 99% of the cases. > >> There is no such problem. There only Analogy. > >> > > > > I'm not discussing Analogy at all, those drivers are still biased by the > > legacy 2.x logic for dealing with modes and need fixing. I have never > > been convinced by the reasoning behind rtdm_in_rt_context(), which > > perfectly illustrates why messing with the call mode is not the > > application's business. > > You still need rtdm_in_rt_context() for the (rare) case of having the > same handler for both service_rt and service_nrt. That didn't change > with any switching strategy adjustment. It can't as long as there are > services behind a syscall that may handle any mode, thus that syscall is > unable to filter for the service in the background. We really need to > differentiate here.
You do not need rtdm_in_rt_context. By writing a separate _rt and _nrt driver you achieve exactly the same goal. If the the two handlers share some code, put it in a common function. It has always been a choice to use rtdm_in_rt_context. And not a very good one in fact: you get potentially two instruction cache misses instead of just one. -- Gilles. https://click-hack.org _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai