* rt_task_shadow() secondary mode @ 2021-07-08 9:03 Richard Weinberger 2021-07-08 9:25 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Richard Weinberger @ 2021-07-08 9:03 UTC (permalink / raw) To: Xenomai Hi! An application I'm working on assumes that rt_task_shadow() with prio being 0 returns in secondary mode. This seems to be the case on Xenomai 2.6 but no longer on 3.1. Is this a known/desired change? -- Thanks, //richard ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 9:03 rt_task_shadow() secondary mode Richard Weinberger @ 2021-07-08 9:25 ` Jan Kiszka 2021-07-08 9:51 ` Richard Weinberger 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2021-07-08 9:25 UTC (permalink / raw) To: Richard Weinberger, Xenomai On 08.07.21 11:03, Richard Weinberger via Xenomai wrote: > Hi! > > An application I'm working on assumes that rt_task_shadow() with prio > being 0 returns in secondary mode. This seems to be the case on > Xenomai 2.6 but no longer on 3.1. > > Is this a known/desired change? > The general philosophy of Xenomai is that applications should not rely on the exact switching behavior. So the question would be why your application needs one or the other behavior? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 9:25 ` Jan Kiszka @ 2021-07-08 9:51 ` Richard Weinberger 2021-07-08 9:54 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Richard Weinberger @ 2021-07-08 9:51 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: > The general philosophy of Xenomai is that applications should not rely > on the exact switching behavior. So the question would be why your > application needs one or the other behavior? In this particular case the application uses the ioctl() system call to call into a xenomai kernel module. The module implements the rt and nrt variant of ioctl() and the application assumes which version of the ioctl() implementation will get reached. -- Thanks, //richard ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 9:51 ` Richard Weinberger @ 2021-07-08 9:54 ` Jan Kiszka 2021-07-08 10:04 ` Richard Weinberger 2021-07-08 10:09 ` Philippe Gerum 0 siblings, 2 replies; 11+ messages in thread From: Jan Kiszka @ 2021-07-08 9:54 UTC (permalink / raw) To: Richard Weinberger; +Cc: Xenomai On 08.07.21 11:51, Richard Weinberger wrote: > On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: >> The general philosophy of Xenomai is that applications should not rely >> on the exact switching behavior. So the question would be why your >> application needs one or the other behavior? > > In this particular case the application uses the ioctl() system call > to call into a > xenomai kernel module. The module implements the rt and nrt variant of > ioctl() and > the application assumes which version of the ioctl() implementation > will get reached. ...that might be the actual design bug. If a driver implements the a service for both calling modes, the service should effectively do the same, ie. should be mode-agnostic. Seems, this was violated here. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 9:54 ` Jan Kiszka @ 2021-07-08 10:04 ` Richard Weinberger 2021-07-08 10:20 ` Jan Kiszka 2021-07-08 10:09 ` Philippe Gerum 1 sibling, 1 reply; 11+ messages in thread From: Richard Weinberger @ 2021-07-08 10:04 UTC (permalink / raw) To: Jan Kiszka; +Cc: Xenomai On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: > > On 08.07.21 11:51, Richard Weinberger wrote: > > On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: > >> The general philosophy of Xenomai is that applications should not rely > >> on the exact switching behavior. So the question would be why your > >> application needs one or the other behavior? > > > > In this particular case the application uses the ioctl() system call > > to call into a > > xenomai kernel module. The module implements the rt and nrt variant of > > ioctl() and > > the application assumes which version of the ioctl() implementation > > will get reached. > > ...that might be the actual design bug. If a driver implements the a > service for both calling modes, the service should effectively do the > same, ie. should be mode-agnostic. Seems, this was violated here. Can be, the driver was designed a long time ago. :-) In the nrt ioctl() the driver uses e.g. ioremap(), this cannot work in primary mode. Is the desired approach switching to secondary mode when in primary mode such a code path is to be executed? -- Thanks, //richard ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 10:04 ` Richard Weinberger @ 2021-07-08 10:20 ` Jan Kiszka 0 siblings, 0 replies; 11+ messages in thread From: Jan Kiszka @ 2021-07-08 10:20 UTC (permalink / raw) To: Richard Weinberger; +Cc: Xenomai On 08.07.21 12:04, Richard Weinberger wrote: > On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: >> >> On 08.07.21 11:51, Richard Weinberger wrote: >>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>> The general philosophy of Xenomai is that applications should not rely >>>> on the exact switching behavior. So the question would be why your >>>> application needs one or the other behavior? >>> >>> In this particular case the application uses the ioctl() system call >>> to call into a >>> xenomai kernel module. The module implements the rt and nrt variant of >>> ioctl() and >>> the application assumes which version of the ioctl() implementation >>> will get reached. >> >> ...that might be the actual design bug. If a driver implements the a >> service for both calling modes, the service should effectively do the >> same, ie. should be mode-agnostic. Seems, this was violated here. > > Can be, the driver was designed a long time ago. :-) > In the nrt ioctl() the driver uses e.g. ioremap(), this cannot work in primary > mode. Is the desired approach switching to secondary mode when in primary > mode such a code path is to be executed? > Correct. That is easily achieved by returning -ENOSYS from the rt handler when seeing that nrt request in its context. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 9:54 ` Jan Kiszka 2021-07-08 10:04 ` Richard Weinberger @ 2021-07-08 10:09 ` Philippe Gerum 2021-07-08 10:23 ` Jan Kiszka 1 sibling, 1 reply; 11+ messages in thread From: Philippe Gerum @ 2021-07-08 10:09 UTC (permalink / raw) To: Jan Kiszka; +Cc: Richard Weinberger, xenomai Jan Kiszka via Xenomai <xenomai@xenomai.org> writes: > On 08.07.21 11:51, Richard Weinberger wrote: >> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> The general philosophy of Xenomai is that applications should not rely >>> on the exact switching behavior. So the question would be why your >>> application needs one or the other behavior? >> >> In this particular case the application uses the ioctl() system call >> to call into a >> xenomai kernel module. The module implements the rt and nrt variant of >> ioctl() and >> the application assumes which version of the ioctl() implementation >> will get reached. > > ...that might be the actual design bug. If a driver implements the a > service for both calling modes, the service should effectively do the > same, ie. should be mode-agnostic. Seems, this was violated here. > > Jan True, but this said, rt_task_shadow() should definitely leave the caller into secondary mode if called for SCHED_OTHER, since this would be the natural execution stage in that case. So rt_task_shadow() behaves like the documentation states, but should not in this particular case (prio=0). -- Philippe. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 10:09 ` Philippe Gerum @ 2021-07-08 10:23 ` Jan Kiszka 2021-07-08 12:51 ` Philippe Gerum 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2021-07-08 10:23 UTC (permalink / raw) To: Philippe Gerum; +Cc: Richard Weinberger, xenomai On 08.07.21 12:09, Philippe Gerum wrote: > > Jan Kiszka via Xenomai <xenomai@xenomai.org> writes: > >> On 08.07.21 11:51, Richard Weinberger wrote: >>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>> The general philosophy of Xenomai is that applications should not rely >>>> on the exact switching behavior. So the question would be why your >>>> application needs one or the other behavior? >>> >>> In this particular case the application uses the ioctl() system call >>> to call into a >>> xenomai kernel module. The module implements the rt and nrt variant of >>> ioctl() and >>> the application assumes which version of the ioctl() implementation >>> will get reached. >> >> ...that might be the actual design bug. If a driver implements the a >> service for both calling modes, the service should effectively do the >> same, ie. should be mode-agnostic. Seems, this was violated here. >> >> Jan > > True, but this said, rt_task_shadow() should definitely leave the caller > into secondary mode if called for SCHED_OTHER, since this would be the > natural execution stage in that case. So rt_task_shadow() behaves like > the documentation states, but should not in this particular case > (prio=0). > Then it needs to be understood what technically triggers this and resolved, likely via an explicit migration. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 10:23 ` Jan Kiszka @ 2021-07-08 12:51 ` Philippe Gerum 2021-07-08 22:05 ` Richard Weinberger 0 siblings, 1 reply; 11+ messages in thread From: Philippe Gerum @ 2021-07-08 12:51 UTC (permalink / raw) To: Jan Kiszka; +Cc: Richard Weinberger, xenomai Jan Kiszka <jan.kiszka@siemens.com> writes: > On 08.07.21 12:09, Philippe Gerum wrote: >> >> Jan Kiszka via Xenomai <xenomai@xenomai.org> writes: >> >>> On 08.07.21 11:51, Richard Weinberger wrote: >>>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>> The general philosophy of Xenomai is that applications should not rely >>>>> on the exact switching behavior. So the question would be why your >>>>> application needs one or the other behavior? >>>> >>>> In this particular case the application uses the ioctl() system call >>>> to call into a >>>> xenomai kernel module. The module implements the rt and nrt variant of >>>> ioctl() and >>>> the application assumes which version of the ioctl() implementation >>>> will get reached. >>> >>> ...that might be the actual design bug. If a driver implements the a >>> service for both calling modes, the service should effectively do the >>> same, ie. should be mode-agnostic. Seems, this was violated here. >>> >>> Jan >> >> True, but this said, rt_task_shadow() should definitely leave the caller >> into secondary mode if called for SCHED_OTHER, since this would be the >> natural execution stage in that case. So rt_task_shadow() behaves like >> the documentation states, but should not in this particular case >> (prio=0). >> > > Then it needs to be understood what technically triggers this and > resolved, likely via an explicit migration. > Sure, good exercise for the reader to get ones feet wet with libalchemy. If somebody wants to tackle this: check callers of threadobj_run_corespec() in libcopperplate. The common case in this routine is to force a switch back to primary mode for the caller, on exit from threadobj_shadow(). We may want to make this conditional to the scheduling policy and priority. Following threadobj_init() for the content of idata may help too. -- Philippe. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 12:51 ` Philippe Gerum @ 2021-07-08 22:05 ` Richard Weinberger 2021-07-08 22:14 ` Richard Weinberger 0 siblings, 1 reply; 11+ messages in thread From: Richard Weinberger @ 2021-07-08 22:05 UTC (permalink / raw) To: Philippe Gerum; +Cc: Jan Kiszka, Xenomai On Thu, Jul 8, 2021 at 2:51 PM Philippe Gerum <rpm@xenomai.org> wrote: > > Then it needs to be understood what technically triggers this and > > resolved, likely via an explicit migration. > > > > Sure, good exercise for the reader to get ones feet wet with libalchemy. > If somebody wants to tackle this: check callers of > threadobj_run_corespec() in libcopperplate. > > The common case in this routine is to force a switch back to primary > mode for the caller, on exit from threadobj_shadow(). We may want to > make this conditional to the scheduling policy and priority. Following > threadobj_init() for the content of idata may help too. Hmm. I see cobalt_thread_harden() being called long before threadobj_init(). cobalt_thread_trampoline() calls it too. Same for pthread_setschedparam_ex() if the task in question is main(). -- Thanks, //richard ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: rt_task_shadow() secondary mode 2021-07-08 22:05 ` Richard Weinberger @ 2021-07-08 22:14 ` Richard Weinberger 0 siblings, 0 replies; 11+ messages in thread From: Richard Weinberger @ 2021-07-08 22:14 UTC (permalink / raw) To: Philippe Gerum; +Cc: Jan Kiszka, Xenomai On Fri, Jul 9, 2021 at 12:05 AM Richard Weinberger <richard.weinberger@gmail.com> wrote: > Hmm. > I see cobalt_thread_harden() being called long before threadobj_init(). > cobalt_thread_trampoline() calls it too. > Same for pthread_setschedparam_ex() if the task in question is main(). Correction: It is always pthread_setschedparam_ex(). I forgot that I had pthread_create wrapping enabled in one test... -- Thanks, //richard ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-07-08 22:14 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-08 9:03 rt_task_shadow() secondary mode Richard Weinberger 2021-07-08 9:25 ` Jan Kiszka 2021-07-08 9:51 ` Richard Weinberger 2021-07-08 9:54 ` Jan Kiszka 2021-07-08 10:04 ` Richard Weinberger 2021-07-08 10:20 ` Jan Kiszka 2021-07-08 10:09 ` Philippe Gerum 2021-07-08 10:23 ` Jan Kiszka 2021-07-08 12:51 ` Philippe Gerum 2021-07-08 22:05 ` Richard Weinberger 2021-07-08 22:14 ` Richard Weinberger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.