* [Xenomai-help] Analogy cmd_write example explanation @ 2010-03-10 15:26 Daniele Nicolodi 2010-03-12 23:40 ` Alexis Berlemont 0 siblings, 1 reply; 46+ messages in thread From: Daniele Nicolodi @ 2010-03-10 15:26 UTC (permalink / raw) To: xenomai Hello. I'm looking into the analogy cmd_write example. I'm not sure I understand the reason for the rt_task_set_mode() function call into the data acquisition loop (lines 413 or 464 in the code shipped with xenomai 2.5.1). I do not understand why we have to set the primary mode at every iteration, when we set it before for the task (line 380). Is it because the dump_function() uses system calls that can make the task to switch to secondary mode, or there is a deeper reason I'm missing? Thanks. Cheers, -- Daniele ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-10 15:26 [Xenomai-help] Analogy cmd_write example explanation Daniele Nicolodi @ 2010-03-12 23:40 ` Alexis Berlemont 2010-03-13 9:28 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Alexis Berlemont @ 2010-03-12 23:40 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: xenomai Hi, Sorry for answering so late. I took a few days off far from any internet connection. It seems you sent many mails related with Analogy. Many thanks for your interest. I have not read all of them yet. However, I am beginning by this one (which seems unanswered). The answer is quick and easy :) Daniele Nicolodi wrote: > Hello. I'm looking into the analogy cmd_write example. > > I'm not sure I understand the reason for the rt_task_set_mode() function > call into the data acquisition loop (lines 413 or 464 in the code > shipped with xenomai 2.5.1). > > I do not understand why we have to set the primary mode at every > iteration, when we set it before for the task (line 380). > > Is it because the dump_function() uses system calls that can make the > task to switch to secondary mode, or there is a deeper reason I'm missing? > You are right. The dumping routine triggers a switch to secondary mode. That is why, the program switches back to primary mode after. Almost all the Analogy programs (cmd_read, cmd_write, insn_read, insn_write, insn_bits) are just demonstration examples. That is why the code is so linear, lengthy and repetitive. Furthermore, the code was not meant to be efficient. I just wanted to test the RT and NRT entries. By the way, I started to improve them. One change (which is still missing) is the use of rtdk. > Thanks. Cheers, Alexis. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-12 23:40 ` Alexis Berlemont @ 2010-03-13 9:28 ` Philippe Gerum 2010-03-13 16:13 ` Alexis Berlemont 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-03-13 9:28 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > Hi, > > Sorry for answering so late. I took a few days off far from any internet > connection. > > It seems you sent many mails related with Analogy. Many thanks for your > interest. I have not read all of them yet. However, I am beginning by > this one (which seems unanswered). The answer is quick and easy :) > > Daniele Nicolodi wrote: > > Hello. I'm looking into the analogy cmd_write example. > > > > I'm not sure I understand the reason for the rt_task_set_mode() function > > call into the data acquisition loop (lines 413 or 464 in the code > > shipped with xenomai 2.5.1). > > > > I do not understand why we have to set the primary mode at every > > iteration, when we set it before for the task (line 380). > > > > Is it because the dump_function() uses system calls that can make the > > task to switch to secondary mode, or there is a deeper reason I'm missing? > > > You are right. The dumping routine triggers a switch to secondary mode. > That is why, the program switches back to primary mode after. This is wrong. The Xenomai core will switch your real-time thread to primary mode automatically when running a4l_insn* calls that end up invoking rt_dev_ioctl(), since you did declare a real-time entry point for this one. Let's summarize the whole point of forcing primary mode through rt_task_set_mode(): it's bad, it's wrong, it's counter-productive CPU-wise, it usually reveals a design issue in the calling code in most cases. The only application-level use case where switching to primary mode eagerly this way might make sense, is when the code first switches to secondary, then runs an awful lot of CPU-intensive code without issuing any syscall, one might want to keep un-preempted from Linux IRQs. In such a case, the question which arises immediately is: why the hell does one ever tolerate switching to secondary mode initially, if strict timely behavior is wanted later on? That crap is a freaking mistake of mine, when I exported such anti-feature via the native API mindlessly, to provide a work-around for rare situations some internal Xenomai code might benefit from. I should have provided an internal syscall instead, to hide this monster deep into the abyssal zone it should never have left. In short: DO NOT USE THIS. > > Almost all the Analogy programs (cmd_read, cmd_write, insn_read, > insn_write, insn_bits) are just demonstration examples. That is why the > code is so linear, lengthy and repetitive. Furthermore, the code was not > meant to be efficient. I just wanted to test the RT and NRT entries. > > By the way, I started to improve them. One change (which is still > missing) is the use of rtdk. > > > Thanks. Cheers, > > Alexis. > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-13 9:28 ` Philippe Gerum @ 2010-03-13 16:13 ` Alexis Berlemont 2010-03-13 16:33 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Alexis Berlemont @ 2010-03-13 16:13 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Hi, Philippe Gerum wrote: > On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >> Hi, >> >> Sorry for answering so late. I took a few days off far from any internet >> connection. >> >> It seems you sent many mails related with Analogy. Many thanks for your >> interest. I have not read all of them yet. However, I am beginning by >> this one (which seems unanswered). The answer is quick and easy :) >> >> Daniele Nicolodi wrote: >>> Hello. I'm looking into the analogy cmd_write example. >>> >>> I'm not sure I understand the reason for the rt_task_set_mode() function >>> call into the data acquisition loop (lines 413 or 464 in the code >>> shipped with xenomai 2.5.1). >>> >>> I do not understand why we have to set the primary mode at every >>> iteration, when we set it before for the task (line 380). >>> >>> Is it because the dump_function() uses system calls that can make the >>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>> >> You are right. The dumping routine triggers a switch to secondary mode. >> That is why, the program switches back to primary mode after. > > This is wrong. The Xenomai core will switch your real-time thread to > primary mode automatically when running a4l_insn* calls that end up > invoking rt_dev_ioctl(), since you did declare a real-time entry point > for this one. > I don't understand. I thought that rt_dev_ioctl() triggered an __rtdm_ioctl syscall, which, according to the rtdm systab, is declared with the flags "__xn_exec_current | __xn_exec_adaptive". So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will return -ENOSYS neither in RT nor in NRT mode (because analogy declares both RT and NRT fops entries), I thought there was no automatic mode-switching. So, for me, an RT task running in secondary mode, which triggers an RTDM ioctl, stays in the current mode (NRT mode) if the RTDM IOCTL NRT handler is available. For me, switching back to primary mode if the RT handler is available is not the current behaviour. What did I miss ? > Let's summarize the whole point of forcing primary mode through > rt_task_set_mode(): it's bad, it's wrong, it's counter-productive > CPU-wise, it usually reveals a design issue in the calling code in most > cases. > > The only application-level use case where switching to primary mode > eagerly this way might make sense, is when the code first switches to > secondary, then runs an awful lot of CPU-intensive code without issuing > any syscall, one might want to keep un-preempted from Linux IRQs. In > such a case, the question which arises immediately is: why the hell does > one ever tolerate switching to secondary mode initially, if strict > timely behavior is wanted later on? > > That crap is a freaking mistake of mine, when I exported such > anti-feature via the native API mindlessly, to provide a work-around for > rare situations some internal Xenomai code might benefit from. I should > have provided an internal syscall instead, to hide this monster deep > into the abyssal zone it should never have left. > > In short: DO NOT USE THIS. I will remove it in cmd_read and cmd_write. > >> Almost all the Analogy programs (cmd_read, cmd_write, insn_read, >> insn_write, insn_bits) are just demonstration examples. That is why the >> code is so linear, lengthy and repetitive. Furthermore, the code was not >> meant to be efficient. I just wanted to test the RT and NRT entries. >> >> By the way, I started to improve them. One change (which is still >> missing) is the use of rtdk. >> >>> Thanks. Cheers, >> Alexis. >> >> _______________________________________________ >> Xenomai-help mailing list >> Xenomai-help@domain.hid >> https://mail.gna.org/listinfo/xenomai-help > > Alexis. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-13 16:13 ` Alexis Berlemont @ 2010-03-13 16:33 ` Philippe Gerum 2010-03-13 23:34 ` Alexis Berlemont 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-03-13 16:33 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > Hi, > > Philippe Gerum wrote: > > On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >> Hi, > >> > >> Sorry for answering so late. I took a few days off far from any internet > >> connection. > >> > >> It seems you sent many mails related with Analogy. Many thanks for your > >> interest. I have not read all of them yet. However, I am beginning by > >> this one (which seems unanswered). The answer is quick and easy :) > >> > >> Daniele Nicolodi wrote: > >>> Hello. I'm looking into the analogy cmd_write example. > >>> > >>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>> call into the data acquisition loop (lines 413 or 464 in the code > >>> shipped with xenomai 2.5.1). > >>> > >>> I do not understand why we have to set the primary mode at every > >>> iteration, when we set it before for the task (line 380). > >>> > >>> Is it because the dump_function() uses system calls that can make the > >>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>> > >> You are right. The dumping routine triggers a switch to secondary mode. > >> That is why, the program switches back to primary mode after. > > > > This is wrong. The Xenomai core will switch your real-time thread to > > primary mode automatically when running a4l_insn* calls that end up > > invoking rt_dev_ioctl(), since you did declare a real-time entry point > > for this one. > > > > I don't understand. I thought that rt_dev_ioctl() triggered an > __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > with the flags "__xn_exec_current | __xn_exec_adaptive". > > So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > return -ENOSYS neither in RT nor in NRT mode (because analogy declares > both RT and NRT fops entries), I thought there was no automatic > mode-switching. The point is that your ioctl_nrt handler should return -ENOSYS when it detects that the current request should be processed by the converse domain, to trigger the switch to primary mode. This is why the adaptive tag is provided in the first place. If the above can't be done, this means that such ioctl request has a different implementation for a real-time task, depending on whether it runs in primary or secondary mode, which would turn out to be the basic issue: this would be ambiguous and very much error-prone. This is where relying on rt_task_set_mode() may reveal design issues. > > So, for me, an RT task running in secondary mode, which triggers an RTDM > ioctl, stays in the current mode (NRT mode) if the RTDM IOCTL NRT > handler is available. For me, switching back to primary mode if the RT > handler is available is not the current behaviour. > > What did I miss ? > > > Let's summarize the whole point of forcing primary mode through > > rt_task_set_mode(): it's bad, it's wrong, it's counter-productive > > CPU-wise, it usually reveals a design issue in the calling code in most > > cases. > > > > The only application-level use case where switching to primary mode > > eagerly this way might make sense, is when the code first switches to > > secondary, then runs an awful lot of CPU-intensive code without issuing > > any syscall, one might want to keep un-preempted from Linux IRQs. In > > such a case, the question which arises immediately is: why the hell does > > one ever tolerate switching to secondary mode initially, if strict > > timely behavior is wanted later on? > > > > That crap is a freaking mistake of mine, when I exported such > > anti-feature via the native API mindlessly, to provide a work-around for > > rare situations some internal Xenomai code might benefit from. I should > > have provided an internal syscall instead, to hide this monster deep > > into the abyssal zone it should never have left. > > > > In short: DO NOT USE THIS. > > I will remove it in cmd_read and cmd_write. > > > > >> Almost all the Analogy programs (cmd_read, cmd_write, insn_read, > >> insn_write, insn_bits) are just demonstration examples. That is why the > >> code is so linear, lengthy and repetitive. Furthermore, the code was not > >> meant to be efficient. I just wanted to test the RT and NRT entries. > >> > >> By the way, I started to improve them. One change (which is still > >> missing) is the use of rtdk. > >> > >>> Thanks. Cheers, > >> Alexis. > >> > >> _______________________________________________ > >> Xenomai-help mailing list > >> Xenomai-help@domain.hid > >> https://mail.gna.org/listinfo/xenomai-help > > > > > > Alexis. -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-13 16:33 ` Philippe Gerum @ 2010-03-13 23:34 ` Alexis Berlemont 2010-03-14 16:34 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Alexis Berlemont @ 2010-03-13 23:34 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Philippe Gerum wrote: > On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >> Hi, >> >> Philippe Gerum wrote: >>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>> Hi, >>>> >>>> Sorry for answering so late. I took a few days off far from any internet >>>> connection. >>>> >>>> It seems you sent many mails related with Analogy. Many thanks for your >>>> interest. I have not read all of them yet. However, I am beginning by >>>> this one (which seems unanswered). The answer is quick and easy :) >>>> >>>> Daniele Nicolodi wrote: >>>>> Hello. I'm looking into the analogy cmd_write example. >>>>> >>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>> shipped with xenomai 2.5.1). >>>>> >>>>> I do not understand why we have to set the primary mode at every >>>>> iteration, when we set it before for the task (line 380). >>>>> >>>>> Is it because the dump_function() uses system calls that can make the >>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>> >>>> You are right. The dumping routine triggers a switch to secondary mode. >>>> That is why, the program switches back to primary mode after. >>> This is wrong. The Xenomai core will switch your real-time thread to >>> primary mode automatically when running a4l_insn* calls that end up >>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>> for this one. >>> >> I don't understand. I thought that rt_dev_ioctl() triggered an >> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >> with the flags "__xn_exec_current | __xn_exec_adaptive". >> >> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >> both RT and NRT fops entries), I thought there was no automatic >> mode-switching. > > The point is that your ioctl_nrt handler should return -ENOSYS when it > detects that the current request should be processed by the converse > domain, to trigger the switch to primary mode. This is why the adaptive > tag is provided in the first place. The problem is that rtdm does not provide any function to know whether the thread is shadowed. We just have rtdm_in_rt_context() which tells us whether the thread is RT or not. If it is NRT, we cannot distinguish a Linux thread from a Xenomai one. I thought with a little patch like this in ksrc/skins/rtdm/core.c, we could force -ENOSYS if the calling thread was a Xenomai NRT thread: diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c index 8677c47..cc0cfe9 100644 --- a/ksrc/skins/rtdm/core.c +++ b/ksrc/skins/rtdm/core.c @@ -423,6 +423,9 @@ do { \ \ if (rtdm_in_rt_context()) \ ret = ops->operation##_rt(context, user_info, args); \ + else if (xnshadow_thread(user_info) != NULL && \ + ops->operation##_rt != (void *)rtdm_no_support) \ + ret = -ENOSYS; \ else \ ret = ops->operation##_nrt(context, user_info, args); \ \ However, that patch triggers a problem, some Analogy ioctls (mmap and bufconfig) needs to be done in NRT context. So, the forcing makes their executions impossible. Maybe the solution would be adding a function rtdm_in_shadowed_context() in the rtdm api: static inline int rtdm_in_shadow_context(rtdm_user_info_t *user_info) { return (xnshadow_thread(user_info) != NULL); } > > If the above can't be done, this means that such ioctl request has a > different implementation for a real-time task, depending on whether it > runs in primary or secondary mode, which would turn out to be the basic > issue: this would be ambiguous and very much error-prone. This is where > relying on rt_task_set_mode() may reveal design issues. > >> So, for me, an RT task running in secondary mode, which triggers an RTDM >> ioctl, stays in the current mode (NRT mode) if the RTDM IOCTL NRT >> handler is available. For me, switching back to primary mode if the RT >> handler is available is not the current behaviour. >> >> What did I miss ? >> >>> Let's summarize the whole point of forcing primary mode through >>> rt_task_set_mode(): it's bad, it's wrong, it's counter-productive >>> CPU-wise, it usually reveals a design issue in the calling code in most >>> cases. >>> >>> The only application-level use case where switching to primary mode >>> eagerly this way might make sense, is when the code first switches to >>> secondary, then runs an awful lot of CPU-intensive code without issuing >>> any syscall, one might want to keep un-preempted from Linux IRQs. In >>> such a case, the question which arises immediately is: why the hell does >>> one ever tolerate switching to secondary mode initially, if strict >>> timely behavior is wanted later on? >>> >>> That crap is a freaking mistake of mine, when I exported such >>> anti-feature via the native API mindlessly, to provide a work-around for >>> rare situations some internal Xenomai code might benefit from. I should >>> have provided an internal syscall instead, to hide this monster deep >>> into the abyssal zone it should never have left. >>> >>> In short: DO NOT USE THIS. >> I will remove it in cmd_read and cmd_write. >> >>>> Almost all the Analogy programs (cmd_read, cmd_write, insn_read, >>>> insn_write, insn_bits) are just demonstration examples. That is why the >>>> code is so linear, lengthy and repetitive. Furthermore, the code was not >>>> meant to be efficient. I just wanted to test the RT and NRT entries. >>>> >>>> By the way, I started to improve them. One change (which is still >>>> missing) is the use of rtdk. >>>> >>>>> Thanks. Cheers, >>>> Alexis. >>>> >>>> _______________________________________________ >>>> Xenomai-help mailing list >>>> Xenomai-help@domain.hid >>>> https://mail.gna.org/listinfo/xenomai-help >>> >> Alexis. > > Alexis. ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-13 23:34 ` Alexis Berlemont @ 2010-03-14 16:34 ` Philippe Gerum 2010-03-15 7:50 ` Jan Kiszka 2010-04-01 19:47 ` Gilles Chanteperdrix 0 siblings, 2 replies; 46+ messages in thread From: Philippe Gerum @ 2010-03-14 16:34 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai, Jan Kiszka On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > Philippe Gerum wrote: > > On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >> Hi, > >> > >> Philippe Gerum wrote: > >>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>> Hi, > >>>> > >>>> Sorry for answering so late. I took a few days off far from any internet > >>>> connection. > >>>> > >>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>> interest. I have not read all of them yet. However, I am beginning by > >>>> this one (which seems unanswered). The answer is quick and easy :) > >>>> > >>>> Daniele Nicolodi wrote: > >>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>> > >>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>> shipped with xenomai 2.5.1). > >>>>> > >>>>> I do not understand why we have to set the primary mode at every > >>>>> iteration, when we set it before for the task (line 380). > >>>>> > >>>>> Is it because the dump_function() uses system calls that can make the > >>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>> > >>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>> That is why, the program switches back to primary mode after. > >>> This is wrong. The Xenomai core will switch your real-time thread to > >>> primary mode automatically when running a4l_insn* calls that end up > >>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>> for this one. > >>> > >> I don't understand. I thought that rt_dev_ioctl() triggered an > >> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >> with the flags "__xn_exec_current | __xn_exec_adaptive". > >> > >> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >> both RT and NRT fops entries), I thought there was no automatic > >> mode-switching. > > > > The point is that your ioctl_nrt handler should return -ENOSYS when it > > detects that the current request should be processed by the converse > > domain, to trigger the switch to primary mode. This is why the adaptive > > tag is provided in the first place. > The problem is that rtdm does not provide any function to know whether > the thread is shadowed. We just have rtdm_in_rt_context() which tells us > whether the thread is RT or not. If it is NRT, we cannot distinguish a > Linux thread from a Xenomai one. > > I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > could force -ENOSYS if the calling thread was a Xenomai NRT thread: > > diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > index 8677c47..cc0cfe9 100644 > --- a/ksrc/skins/rtdm/core.c > +++ b/ksrc/skins/rtdm/core.c > @@ -423,6 +423,9 @@ do { \ > \ > if (rtdm_in_rt_context()) \ > ret = ops->operation##_rt(context, user_info, args); \ > + else if (xnshadow_thread(user_info) != NULL && \ > + ops->operation##_rt != (void *)rtdm_no_support) \ > + ret = -ENOSYS; \ > else \ > ret = ops->operation##_nrt(context, user_info, args); \ > \ No, this would be a half-working kludge. But I think you have pinpointed a more general issue with RTDM: syscalls should be tagged as both adaptive and conforming, instead of bearing the __xn_exec_current bit. Actually, we do want the current domain to change when it is not the most appropriate, which __xn_exec_current prevents so far. What we rather want is to have shadows migrating to primary mode when running rtdm_ioctl, since this is the preferred mode of operation for Xenomai threads, so that ioctl_rt is always invoked first when present, giving an opportunity to forward the request to secondary mode by returning -ENOSYS. Conforming calls always enforce the preferred runtime mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. That logic applies to all RTDM syscalls actually. __xn_exec_current allows application code to infer that the RTDM driver might behave differently depending on the current runtime mode of the calling thread, which is very much error-prone, and likely not what was envisioned initially. Jan? diff --git a/ksrc/skins/rtdm/syscall.c b/ksrc/skins/rtdm/syscall.c index 80785ab..5fb340d 100644 --- a/ksrc/skins/rtdm/syscall.c +++ b/ksrc/skins/rtdm/syscall.c @@ -154,7 +154,7 @@ static xnsysent_t __systab[] = { [__rtdm_close] = {sys_rtdm_close, __xn_exec_current | __xn_exec_adaptive}, [__rtdm_ioctl] = - {sys_rtdm_ioctl, __xn_exec_current | __xn_exec_adaptive}, + {sys_rtdm_ioctl, __xn_exec_conforming | __xn_exec_adaptive}, [__rtdm_read] = {sys_rtdm_read, __xn_exec_current | __xn_exec_adaptive}, [__rtdm_write] = {sys_rtdm_write, __xn_exec_current | __xn_exec_adaptive}, > > However, that patch triggers a problem, some Analogy ioctls (mmap and > bufconfig) needs to be done in NRT context. So, the forcing makes their > executions impossible. > > Maybe the solution would be adding a function rtdm_in_shadowed_context() > in the rtdm api: > > static inline int rtdm_in_shadow_context(rtdm_user_info_t *user_info) > { > return (xnshadow_thread(user_info) != NULL); > } > > > > > If the above can't be done, this means that such ioctl request has a > > different implementation for a real-time task, depending on whether it > > runs in primary or secondary mode, which would turn out to be the basic > > issue: this would be ambiguous and very much error-prone. This is where > > relying on rt_task_set_mode() may reveal design issues. > > > >> So, for me, an RT task running in secondary mode, which triggers an RTDM > >> ioctl, stays in the current mode (NRT mode) if the RTDM IOCTL NRT > >> handler is available. For me, switching back to primary mode if the RT > >> handler is available is not the current behaviour. > >> > >> What did I miss ? > >> > >>> Let's summarize the whole point of forcing primary mode through > >>> rt_task_set_mode(): it's bad, it's wrong, it's counter-productive > >>> CPU-wise, it usually reveals a design issue in the calling code in most > >>> cases. > >>> > >>> The only application-level use case where switching to primary mode > >>> eagerly this way might make sense, is when the code first switches to > >>> secondary, then runs an awful lot of CPU-intensive code without issuing > >>> any syscall, one might want to keep un-preempted from Linux IRQs. In > >>> such a case, the question which arises immediately is: why the hell does > >>> one ever tolerate switching to secondary mode initially, if strict > >>> timely behavior is wanted later on? > >>> > >>> That crap is a freaking mistake of mine, when I exported such > >>> anti-feature via the native API mindlessly, to provide a work-around for > >>> rare situations some internal Xenomai code might benefit from. I should > >>> have provided an internal syscall instead, to hide this monster deep > >>> into the abyssal zone it should never have left. > >>> > >>> In short: DO NOT USE THIS. > >> I will remove it in cmd_read and cmd_write. > >> > >>>> Almost all the Analogy programs (cmd_read, cmd_write, insn_read, > >>>> insn_write, insn_bits) are just demonstration examples. That is why the > >>>> code is so linear, lengthy and repetitive. Furthermore, the code was not > >>>> meant to be efficient. I just wanted to test the RT and NRT entries. > >>>> > >>>> By the way, I started to improve them. One change (which is still > >>>> missing) is the use of rtdk. > >>>> > >>>>> Thanks. Cheers, > >>>> Alexis. > >>>> > >>>> _______________________________________________ > >>>> Xenomai-help mailing list > >>>> Xenomai-help@domain.hid > >>>> https://mail.gna.org/listinfo/xenomai-help > >>> > >> Alexis. > > > > > > Alexis. -- Philippe. ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-14 16:34 ` Philippe Gerum @ 2010-03-15 7:50 ` Jan Kiszka 2010-03-15 23:30 ` Alexis Berlemont 2010-04-01 19:47 ` Gilles Chanteperdrix 1 sibling, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-03-15 7:50 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 5172 bytes --] Philippe Gerum wrote: > On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >> Philippe Gerum wrote: >>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>> Hi, >>>> >>>> Philippe Gerum wrote: >>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>> Hi, >>>>>> >>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>> connection. >>>>>> >>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>> >>>>>> Daniele Nicolodi wrote: >>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>> >>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>> shipped with xenomai 2.5.1). >>>>>>> >>>>>>> I do not understand why we have to set the primary mode at every >>>>>>> iteration, when we set it before for the task (line 380). >>>>>>> >>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>> >>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>> That is why, the program switches back to primary mode after. >>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>> primary mode automatically when running a4l_insn* calls that end up >>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>> for this one. >>>>> >>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>> >>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>> both RT and NRT fops entries), I thought there was no automatic >>>> mode-switching. >>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>> detects that the current request should be processed by the converse >>> domain, to trigger the switch to primary mode. This is why the adaptive >>> tag is provided in the first place. >> The problem is that rtdm does not provide any function to know whether >> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >> whether the thread is RT or not. If it is NRT, we cannot distinguish a >> Linux thread from a Xenomai one. >> >> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >> >> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >> index 8677c47..cc0cfe9 100644 >> --- a/ksrc/skins/rtdm/core.c >> +++ b/ksrc/skins/rtdm/core.c >> @@ -423,6 +423,9 @@ do { \ >> \ >> if (rtdm_in_rt_context()) \ >> ret = ops->operation##_rt(context, user_info, args); \ >> + else if (xnshadow_thread(user_info) != NULL && \ >> + ops->operation##_rt != (void *)rtdm_no_support) \ >> + ret = -ENOSYS; \ >> else \ >> ret = ops->operation##_nrt(context, user_info, args); \ >> \ > > No, this would be a half-working kludge. But I think you have pinpointed > a more general issue with RTDM: syscalls should be tagged as both > adaptive and conforming, instead of bearing the __xn_exec_current bit. > Actually, we do want the current domain to change when it is not the > most appropriate, which __xn_exec_current prevents so far. > > What we rather want is to have shadows migrating to primary mode when > running rtdm_ioctl, since this is the preferred mode of operation for > Xenomai threads, so that ioctl_rt is always invoked first when present, > giving an opportunity to forward the request to secondary mode by > returning -ENOSYS. Conforming calls always enforce the preferred runtime > mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > That logic applies to all RTDM syscalls actually. > > __xn_exec_current allows application code to infer that the RTDM driver > might behave differently depending on the current runtime mode of the > calling thread, which is very much error-prone, and likely not what was > envisioned initially. Right, this stickiness of RTDM syscalls to the current execution mode conceptually dates back to the days we had users with services provided to both domain. This model is deprecated (e.g. RTnet dropped resources allocation from RT domain, only supports NRT now). So I've no concerns making the call conforming - but... I guess this would just paper over a design issue (or misunderstanding?) in Analogy. Why does it depend on shadow vs. non-shadow at all? The explanations I read so far were not clarifying the reason. Is there any Analogy service that is provided to both domains (via different implementations)? If yes, why? Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-15 7:50 ` Jan Kiszka @ 2010-03-15 23:30 ` Alexis Berlemont 2010-03-16 8:59 ` Jan Kiszka 2010-03-18 20:35 ` Philippe Gerum 0 siblings, 2 replies; 46+ messages in thread From: Alexis Berlemont @ 2010-03-15 23:30 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai Hi, Jan Kiszka wrote: > Philippe Gerum wrote: >> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>> Philippe Gerum wrote: >>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>> Hi, >>>>> >>>>> Philippe Gerum wrote: >>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>>> connection. >>>>>>> >>>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>> >>>>>>> Daniele Nicolodi wrote: >>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>> >>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>> shipped with xenomai 2.5.1). >>>>>>>> >>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>> >>>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>>> >>>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>>> That is why, the program switches back to primary mode after. >>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>>> for this one. >>>>>> >>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>> >>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>>> both RT and NRT fops entries), I thought there was no automatic >>>>> mode-switching. >>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>> detects that the current request should be processed by the converse >>>> domain, to trigger the switch to primary mode. This is why the adaptive >>>> tag is provided in the first place. >>> The problem is that rtdm does not provide any function to know whether >>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>> Linux thread from a Xenomai one. >>> >>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>> >>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>> index 8677c47..cc0cfe9 100644 >>> --- a/ksrc/skins/rtdm/core.c >>> +++ b/ksrc/skins/rtdm/core.c >>> @@ -423,6 +423,9 @@ do { \ >>> \ >>> if (rtdm_in_rt_context()) \ >>> ret = ops->operation##_rt(context, user_info, args); \ >>> + else if (xnshadow_thread(user_info) != NULL && \ >>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>> + ret = -ENOSYS; \ >>> else \ >>> ret = ops->operation##_nrt(context, user_info, args); \ >>> \ >> No, this would be a half-working kludge. But I think you have pinpointed >> a more general issue with RTDM: syscalls should be tagged as both >> adaptive and conforming, instead of bearing the __xn_exec_current bit. >> Actually, we do want the current domain to change when it is not the >> most appropriate, which __xn_exec_current prevents so far. >> >> What we rather want is to have shadows migrating to primary mode when >> running rtdm_ioctl, since this is the preferred mode of operation for >> Xenomai threads, so that ioctl_rt is always invoked first when present, >> giving an opportunity to forward the request to secondary mode by >> returning -ENOSYS. Conforming calls always enforce the preferred runtime >> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >> That logic applies to all RTDM syscalls actually. >> >> __xn_exec_current allows application code to infer that the RTDM driver >> might behave differently depending on the current runtime mode of the >> calling thread, which is very much error-prone, and likely not what was >> envisioned initially. > > Right, this stickiness of RTDM syscalls to the current execution mode > conceptually dates back to the days we had users with services provided > to both domain. This model is deprecated (e.g. RTnet dropped resources > allocation from RT domain, only supports NRT now). > > So I've no concerns making the call conforming - but... I guess this > would just paper over a design issue (or misunderstanding?) in Analogy. > Why does it depend on shadow vs. non-shadow at all? The explanations I > read so far were not clarifying the reason. Is there any Analogy service > that is provided to both domains (via different implementations)? If > yes, why? > Analogy provides all the services in both domains: - the instructions services are synchronous operations; no explicit rescheduling are triggered, consequently, the implementations of the various kinds of instructions displays are the same in both mode; - the commands services allow asynchronous operations; so the handlers behind the read / write fops are the same for RT and NRT entries; however, the event management code relies on rtdm_event in one case and on rtdm_nrtsig + waitqueues in the other case. The main part of the "event" code is located in a4l_wait_sync and a4l_signal_sync. Which design issue do you have in mind ? Concerning your question: why ? Not all the acquisition system users ask for determinism; working with real-time tasks may not be mandatory. So all they need to know is the Analogy API. Furthermore, many acquisition boards have an impressive set of configuration parameters which are accessed via the operations described above. One may be interested in scripting a part of the user application so as to gain development time. I don't want to lose flexibility by confining Analogy to real-time tasks. > Jan > Alexis. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-15 23:30 ` Alexis Berlemont @ 2010-03-16 8:59 ` Jan Kiszka 2010-03-18 20:35 ` Philippe Gerum 1 sibling, 0 replies; 46+ messages in thread From: Jan Kiszka @ 2010-03-16 8:59 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 7694 bytes --] Alexis Berlemont wrote: > Hi, > > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>>> Philippe Gerum wrote: >>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>>> Hi, >>>>>> >>>>>> Philippe Gerum wrote: >>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Sorry for answering so late. I took a few days off far from any >>>>>>>> internet >>>>>>>> connection. >>>>>>>> >>>>>>>> It seems you sent many mails related with Analogy. Many thanks >>>>>>>> for your >>>>>>>> interest. I have not read all of them yet. However, I am >>>>>>>> beginning by >>>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>>> >>>>>>>> Daniele Nicolodi wrote: >>>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>>> >>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() >>>>>>>>> function >>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>>> shipped with xenomai 2.5.1). >>>>>>>>> >>>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>>> >>>>>>>>> Is it because the dump_function() uses system calls that can >>>>>>>>> make the >>>>>>>>> task to switch to secondary mode, or there is a deeper reason >>>>>>>>> I'm missing? >>>>>>>>> >>>>>>>> You are right. The dumping routine triggers a switch to >>>>>>>> secondary mode. >>>>>>>> That is why, the program switches back to primary mode after. >>>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry >>>>>>> point >>>>>>> for this one. >>>>>>> >>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is >>>>>> declared >>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>>> >>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) >>>>>> will >>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy >>>>>> declares >>>>>> both RT and NRT fops entries), I thought there was no automatic >>>>>> mode-switching. >>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>>> detects that the current request should be processed by the converse >>>>> domain, to trigger the switch to primary mode. This is why the >>>>> adaptive >>>>> tag is provided in the first place. >>>> The problem is that rtdm does not provide any function to know whether >>>> the thread is shadowed. We just have rtdm_in_rt_context() which >>>> tells us >>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>>> Linux thread from a Xenomai one. >>>> >>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, >>>> we could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>>> >>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>>> index 8677c47..cc0cfe9 100644 >>>> --- a/ksrc/skins/rtdm/core.c >>>> +++ b/ksrc/skins/rtdm/core.c >>>> @@ -423,6 +423,9 @@ do { \ >>>> \ >>>> if (rtdm_in_rt_context()) \ >>>> ret = ops->operation##_rt(context, user_info, args); \ >>>> + else if (xnshadow_thread(user_info) != NULL && \ >>>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>>> + ret = -ENOSYS; \ >>>> else \ >>>> ret = ops->operation##_nrt(context, user_info, args); \ >>>> \ >>> No, this would be a half-working kludge. But I think you have pinpointed >>> a more general issue with RTDM: syscalls should be tagged as both >>> adaptive and conforming, instead of bearing the __xn_exec_current bit. >>> Actually, we do want the current domain to change when it is not the >>> most appropriate, which __xn_exec_current prevents so far. >>> >>> What we rather want is to have shadows migrating to primary mode when >>> running rtdm_ioctl, since this is the preferred mode of operation for >>> Xenomai threads, so that ioctl_rt is always invoked first when present, >>> giving an opportunity to forward the request to secondary mode by >>> returning -ENOSYS. Conforming calls always enforce the preferred runtime >>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >>> That logic applies to all RTDM syscalls actually. >>> >>> __xn_exec_current allows application code to infer that the RTDM driver >>> might behave differently depending on the current runtime mode of the >>> calling thread, which is very much error-prone, and likely not what was >>> envisioned initially. >> >> Right, this stickiness of RTDM syscalls to the current execution mode >> conceptually dates back to the days we had users with services provided >> to both domain. This model is deprecated (e.g. RTnet dropped resources >> allocation from RT domain, only supports NRT now). >> >> So I've no concerns making the call conforming - but... I guess this >> would just paper over a design issue (or misunderstanding?) in Analogy. >> Why does it depend on shadow vs. non-shadow at all? The explanations I >> read so far were not clarifying the reason. Is there any Analogy service >> that is provided to both domains (via different implementations)? If >> yes, why? >> > > Analogy provides all the services in both domains: > - the instructions services are synchronous operations; no explicit > rescheduling are triggered, consequently, the implementations of the > various kinds of instructions displays are the same in both mode; > - the commands services allow asynchronous operations; so the handlers > behind the read / write fops are the same for RT and NRT entries; > however, the event management code relies on rtdm_event in one case and > on rtdm_nrtsig + waitqueues in the other case. > > The main part of the "event" code is located in a4l_wait_sync and > a4l_signal_sync. > > Which design issue do you have in mind ? I was concerned about resource allocating services for both domains. For that reason, you should drop open_rt & close_rt callbacks even if they may not allocate anything at analogy level ATM, they do at RTDM level. RT resource allocation of RTDM drivers is deprecated (I will remove the corresponding callbacks for Xenomai 3). > > Concerning your question: why ? > > Not all the acquisition system users ask for determinism; working with > real-time tasks may not be mandatory. So all they need to know is the > Analogy API. > > Furthermore, many acquisition boards have an impressive set of > configuration parameters which are accessed via the operations described > above. One may be interested in scripting a part of the user application > so as to gain development time. I don't want to lose flexibility by > confining Analogy to real-time tasks. I can't asses ATM how much this actually buys the typical Analogy user, specifically given that it still takes a Xenomai kernel + user land to use it and shadowing low-prio (SCHED_OTHER) tasks is feasible as well today. But you should at least warn the user that select() is not working that way. It remains restricted to RT tasks as there is no Linux "shadow" FD for the RTDM one. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-15 23:30 ` Alexis Berlemont 2010-03-16 8:59 ` Jan Kiszka @ 2010-03-18 20:35 ` Philippe Gerum 2010-03-18 21:14 ` Alexis Berlemont 1 sibling, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-03-18 20:35 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai, Jan Kiszka On Tue, 2010-03-16 at 00:30 +0100, Alexis Berlemont wrote: > Hi, > > Jan Kiszka wrote: > > Philippe Gerum wrote: > >> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > >>> Philippe Gerum wrote: > >>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >>>>> Hi, > >>>>> > >>>>> Philippe Gerum wrote: > >>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Sorry for answering so late. I took a few days off far from any internet > >>>>>>> connection. > >>>>>>> > >>>>>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>>>>> interest. I have not read all of them yet. However, I am beginning by > >>>>>>> this one (which seems unanswered). The answer is quick and easy :) > >>>>>>> > >>>>>>> Daniele Nicolodi wrote: > >>>>>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>>>>> > >>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>>>>> shipped with xenomai 2.5.1). > >>>>>>>> > >>>>>>>> I do not understand why we have to set the primary mode at every > >>>>>>>> iteration, when we set it before for the task (line 380). > >>>>>>>> > >>>>>>>> Is it because the dump_function() uses system calls that can make the > >>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>>>>> > >>>>>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>>>>> That is why, the program switches back to primary mode after. > >>>>>> This is wrong. The Xenomai core will switch your real-time thread to > >>>>>> primary mode automatically when running a4l_insn* calls that end up > >>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>>>>> for this one. > >>>>>> > >>>>> I don't understand. I thought that rt_dev_ioctl() triggered an > >>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". > >>>>> > >>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >>>>> both RT and NRT fops entries), I thought there was no automatic > >>>>> mode-switching. > >>>> The point is that your ioctl_nrt handler should return -ENOSYS when it > >>>> detects that the current request should be processed by the converse > >>>> domain, to trigger the switch to primary mode. This is why the adaptive > >>>> tag is provided in the first place. > >>> The problem is that rtdm does not provide any function to know whether > >>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us > >>> whether the thread is RT or not. If it is NRT, we cannot distinguish a > >>> Linux thread from a Xenomai one. > >>> > >>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > >>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: > >>> > >>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > >>> index 8677c47..cc0cfe9 100644 > >>> --- a/ksrc/skins/rtdm/core.c > >>> +++ b/ksrc/skins/rtdm/core.c > >>> @@ -423,6 +423,9 @@ do { \ > >>> \ > >>> if (rtdm_in_rt_context()) \ > >>> ret = ops->operation##_rt(context, user_info, args); \ > >>> + else if (xnshadow_thread(user_info) != NULL && \ > >>> + ops->operation##_rt != (void *)rtdm_no_support) \ > >>> + ret = -ENOSYS; \ > >>> else \ > >>> ret = ops->operation##_nrt(context, user_info, args); \ > >>> \ > >> No, this would be a half-working kludge. But I think you have pinpointed > >> a more general issue with RTDM: syscalls should be tagged as both > >> adaptive and conforming, instead of bearing the __xn_exec_current bit. > >> Actually, we do want the current domain to change when it is not the > >> most appropriate, which __xn_exec_current prevents so far. > >> > >> What we rather want is to have shadows migrating to primary mode when > >> running rtdm_ioctl, since this is the preferred mode of operation for > >> Xenomai threads, so that ioctl_rt is always invoked first when present, > >> giving an opportunity to forward the request to secondary mode by > >> returning -ENOSYS. Conforming calls always enforce the preferred runtime > >> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > >> That logic applies to all RTDM syscalls actually. > >> > >> __xn_exec_current allows application code to infer that the RTDM driver > >> might behave differently depending on the current runtime mode of the > >> calling thread, which is very much error-prone, and likely not what was > >> envisioned initially. > > > > Right, this stickiness of RTDM syscalls to the current execution mode > > conceptually dates back to the days we had users with services provided > > to both domain. This model is deprecated (e.g. RTnet dropped resources > > allocation from RT domain, only supports NRT now). > > > > So I've no concerns making the call conforming - but... I guess this > > would just paper over a design issue (or misunderstanding?) in Analogy. > > Why does it depend on shadow vs. non-shadow at all? The explanations I > > read so far were not clarifying the reason. Is there any Analogy service > > that is provided to both domains (via different implementations)? If > > yes, why? > > > > Analogy provides all the services in both domains: > - the instructions services are synchronous operations; no explicit > rescheduling are triggered, consequently, the implementations of the > various kinds of instructions displays are the same in both mode; > - the commands services allow asynchronous operations; so the handlers > behind the read / write fops are the same for RT and NRT entries; > however, the event management code relies on rtdm_event in one case and > on rtdm_nrtsig + waitqueues in the other case. > Actually, the issue is not with having rt and regular tasks accept the very same calls, it is with having the rt tasks potentially run _different code_ for a very same request, depending on whether it is running in primary or secondary mode. That design issue is usually revealed by userland code switching mode eagerly via rt_task_set_mode(), which means that the next syscall(s) may be mode-sensitive, for that task. This is what should be fixed, without implying that you may not define a mode-insensitive API, in order to allow calls from rt _and_ non-rt tasks. Provided the rtdm syscalls you need are made conforming, here is the typical pattern I'm referring to for implementing them: syscall_rt(...) { /* We must be a shadow thread, since we got there */ if (cant_provide_service_in_primary_mode()) /* maybe available from secondary mode? forward it. */ return -ENOSYS; do_service(); } syscall_nrt(...) { /* We could be a shadow thread unable to process the request in primary mode, or a plain linux task. */ do_service(); } > The main part of the "event" code is located in a4l_wait_sync and > a4l_signal_sync. > > Which design issue do you have in mind ? > > Concerning your question: why ? > > Not all the acquisition system users ask for determinism; working with > real-time tasks may not be mandatory. So all they need to know is the > Analogy API. > > Furthermore, many acquisition boards have an impressive set of > configuration parameters which are accessed via the operations described > above. One may be interested in scripting a part of the user application > so as to gain development time. I don't want to lose flexibility by > confining Analogy to real-time tasks. > > > Jan > > > Alexis. -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-18 20:35 ` Philippe Gerum @ 2010-03-18 21:14 ` Alexis Berlemont 2010-03-18 21:39 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Alexis Berlemont @ 2010-03-18 21:14 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai, Jan Kiszka Philippe Gerum wrote: > On Tue, 2010-03-16 at 00:30 +0100, Alexis Berlemont wrote: >> Hi, >> >> Jan Kiszka wrote: >>> Philippe Gerum wrote: >>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>>>> Philippe Gerum wrote: >>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Philippe Gerum wrote: >>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>>>>> connection. >>>>>>>>> >>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>>>> >>>>>>>>> Daniele Nicolodi wrote: >>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>>>> >>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>>>> shipped with xenomai 2.5.1). >>>>>>>>>> >>>>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>>>> >>>>>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>>>>> >>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>>>>> That is why, the program switches back to primary mode after. >>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>>>>> for this one. >>>>>>>> >>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>>>> >>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>>>>> both RT and NRT fops entries), I thought there was no automatic >>>>>>> mode-switching. >>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>>>> detects that the current request should be processed by the converse >>>>>> domain, to trigger the switch to primary mode. This is why the adaptive >>>>>> tag is provided in the first place. >>>>> The problem is that rtdm does not provide any function to know whether >>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>>>> Linux thread from a Xenomai one. >>>>> >>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>>>> >>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>>>> index 8677c47..cc0cfe9 100644 >>>>> --- a/ksrc/skins/rtdm/core.c >>>>> +++ b/ksrc/skins/rtdm/core.c >>>>> @@ -423,6 +423,9 @@ do { \ >>>>> \ >>>>> if (rtdm_in_rt_context()) \ >>>>> ret = ops->operation##_rt(context, user_info, args); \ >>>>> + else if (xnshadow_thread(user_info) != NULL && \ >>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>>>> + ret = -ENOSYS; \ >>>>> else \ >>>>> ret = ops->operation##_nrt(context, user_info, args); \ >>>>> \ >>>> No, this would be a half-working kludge. But I think you have pinpointed >>>> a more general issue with RTDM: syscalls should be tagged as both >>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. >>>> Actually, we do want the current domain to change when it is not the >>>> most appropriate, which __xn_exec_current prevents so far. >>>> >>>> What we rather want is to have shadows migrating to primary mode when >>>> running rtdm_ioctl, since this is the preferred mode of operation for >>>> Xenomai threads, so that ioctl_rt is always invoked first when present, >>>> giving an opportunity to forward the request to secondary mode by >>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime >>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >>>> That logic applies to all RTDM syscalls actually. >>>> >>>> __xn_exec_current allows application code to infer that the RTDM driver >>>> might behave differently depending on the current runtime mode of the >>>> calling thread, which is very much error-prone, and likely not what was >>>> envisioned initially. >>> Right, this stickiness of RTDM syscalls to the current execution mode >>> conceptually dates back to the days we had users with services provided >>> to both domain. This model is deprecated (e.g. RTnet dropped resources >>> allocation from RT domain, only supports NRT now). >>> >>> So I've no concerns making the call conforming - but... I guess this >>> would just paper over a design issue (or misunderstanding?) in Analogy. >>> Why does it depend on shadow vs. non-shadow at all? The explanations I >>> read so far were not clarifying the reason. Is there any Analogy service >>> that is provided to both domains (via different implementations)? If >>> yes, why? >>> >> Analogy provides all the services in both domains: >> - the instructions services are synchronous operations; no explicit >> rescheduling are triggered, consequently, the implementations of the >> various kinds of instructions displays are the same in both mode; >> - the commands services allow asynchronous operations; so the handlers >> behind the read / write fops are the same for RT and NRT entries; >> however, the event management code relies on rtdm_event in one case and >> on rtdm_nrtsig + waitqueues in the other case. >> > > Actually, the issue is not with having rt and regular tasks accept the > very same calls, it is with having the rt tasks potentially run > _different code_ for a very same request, depending on whether it is > running in primary or secondary mode. > > That design issue is usually revealed by userland code switching mode > eagerly via rt_task_set_mode(), which means that the next syscall(s) may > be mode-sensitive, for that task. This is what should be fixed, without > implying that you may not define a mode-insensitive API, in order to > allow calls from rt _and_ non-rt tasks. > > Provided the rtdm syscalls you need are made conforming, here is the > typical pattern I'm referring to for implementing them: > > syscall_rt(...) > { > /* We must be a shadow thread, since we got there */ > if (cant_provide_service_in_primary_mode()) > /* maybe available from secondary mode? forward it. */ > return -ENOSYS; > > do_service(); > } > > syscall_nrt(...) > { > /* We could be a shadow thread unable to process the request in primary > mode, or a plain linux task. */ > > do_service(); > } Yes I understand. I did that two days ago. My git repository will be updated. Is it ok for you ? Author: Alexis Berlemont <alexis.berlemont@domain.hid> 2010-03-16 01:19:23 Committer: Alexis Berlemont <alexis.berlemont@domain.hid> 2010-03-16 01:19:23 Parent: 4be0333bef1a7dd41ef79b4d31209642b05e5593 (analogy: remove rt_task_set_mode from test programs) Child: 0000000000000000000000000000000000000000 (Local uncommitted changes, not checked in to index) Branch: analogy Follows: v2.5.1 Precedes: analogy: change the error code in case of context error (-EPERM -> -ENOSYS) Replace the -EPERM code by the -ENOSYS in bufconfig and mmap ioctls. These two ioctls must be performed in NRT context. With the __xn_exec_adaptive flag, the syscalls may be restarted in the proper domain (NRT in our case) if the suitable error code is sent. ------------------------ ksrc/drivers/analogy/buffer.c ------------------------ index 0c66b4a..aa6acac 100644 @@ -397,8 +397,7 @@ int a4l_ioctl_mmap(a4l_cxt_t *cxt, void *arg) /* The mmap operation cannot be performed in a real-time context */ if (a4l_test_rt() != 0) { - __a4l_err("a4l_ioctl_mmap: mmap must be done in NRT context\n"); - return -EPERM; + return -ENOSYS; } /* Recover the argument structure */ @@ -473,9 +472,7 @@ int a4l_ioctl_bufcfg(a4l_cxt_t * cxt, void *arg) /* As Linux API is used to allocate a virtual buffer, the calling process must not be in primary mode */ if (a4l_test_rt() != 0) { - __a4l_err("a4l_ioctl_bufcfg: buffer config must done " - "in NRT context\n"); - return -EPERM; + return -ENOSYS; } if (rtdm_safe_copy_from_user(cxt->user_info, ------------------------ ksrc/drivers/analogy/device.c ------------------------ index 082053f..ec40b95 100644 @@ -428,7 +428,7 @@ int a4l_ioctl_devcfg(a4l_cxt_t * cxt, void *arg) "a4l_ioctl_devcfg: minor=%d\n", a4l_get_minor(cxt)); if (a4l_test_rt() != 0) - return -EPERM; + return -ENOSYS; if (arg == NULL) { /* Basic checking */ > > > >> The main part of the "event" code is located in a4l_wait_sync and >> a4l_signal_sync. >> >> Which design issue do you have in mind ? >> >> Concerning your question: why ? >> >> Not all the acquisition system users ask for determinism; working with >> real-time tasks may not be mandatory. So all they need to know is the >> Analogy API. >> >> Furthermore, many acquisition boards have an impressive set of >> configuration parameters which are accessed via the operations described >> above. One may be interested in scripting a part of the user application >> so as to gain development time. I don't want to lose flexibility by >> confining Analogy to real-time tasks. >> >>> Jan >>> >> Alexis. > > Alexis. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-18 21:14 ` Alexis Berlemont @ 2010-03-18 21:39 ` Philippe Gerum 0 siblings, 0 replies; 46+ messages in thread From: Philippe Gerum @ 2010-03-18 21:39 UTC (permalink / raw) To: Alexis Berlemont; +Cc: xenomai, Jan Kiszka On Thu, 2010-03-18 at 22:14 +0100, Alexis Berlemont wrote: > Yes I understand. I did that two days ago. My git repository will be > updated. Is it ok for you ? Yes, looks good. -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-03-14 16:34 ` Philippe Gerum 2010-03-15 7:50 ` Jan Kiszka @ 2010-04-01 19:47 ` Gilles Chanteperdrix 2010-04-01 21:13 ` Jan Kiszka ` (2 more replies) 1 sibling, 3 replies; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-01 19:47 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, Jan Kiszka, xenomai Philippe Gerum wrote: > On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >> Philippe Gerum wrote: >>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>> Hi, >>>> >>>> Philippe Gerum wrote: >>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>> Hi, >>>>>> >>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>> connection. >>>>>> >>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>> >>>>>> Daniele Nicolodi wrote: >>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>> >>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>> shipped with xenomai 2.5.1). >>>>>>> >>>>>>> I do not understand why we have to set the primary mode at every >>>>>>> iteration, when we set it before for the task (line 380). >>>>>>> >>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>> >>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>> That is why, the program switches back to primary mode after. >>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>> primary mode automatically when running a4l_insn* calls that end up >>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>> for this one. >>>>> >>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>> >>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>> both RT and NRT fops entries), I thought there was no automatic >>>> mode-switching. >>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>> detects that the current request should be processed by the converse >>> domain, to trigger the switch to primary mode. This is why the adaptive >>> tag is provided in the first place. >> The problem is that rtdm does not provide any function to know whether >> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >> whether the thread is RT or not. If it is NRT, we cannot distinguish a >> Linux thread from a Xenomai one. >> >> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >> >> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >> index 8677c47..cc0cfe9 100644 >> --- a/ksrc/skins/rtdm/core.c >> +++ b/ksrc/skins/rtdm/core.c >> @@ -423,6 +423,9 @@ do { \ >> \ >> if (rtdm_in_rt_context()) \ >> ret = ops->operation##_rt(context, user_info, args); \ >> + else if (xnshadow_thread(user_info) != NULL && \ >> + ops->operation##_rt != (void *)rtdm_no_support) \ >> + ret = -ENOSYS; \ >> else \ >> ret = ops->operation##_nrt(context, user_info, args); \ >> \ > > No, this would be a half-working kludge. But I think you have pinpointed > a more general issue with RTDM: syscalls should be tagged as both > adaptive and conforming, instead of bearing the __xn_exec_current bit. > Actually, we do want the current domain to change when it is not the > most appropriate, which __xn_exec_current prevents so far. > > What we rather want is to have shadows migrating to primary mode when > running rtdm_ioctl, since this is the preferred mode of operation for > Xenomai threads, so that ioctl_rt is always invoked first when present, > giving an opportunity to forward the request to secondary mode by > returning -ENOSYS. Conforming calls always enforce the preferred runtime > mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > That logic applies to all RTDM syscalls actually. > > __xn_exec_current allows application code to infer that the RTDM driver > might behave differently depending on the current runtime mode of the > calling thread, which is very much error-prone, and likely not what was > envisioned initially. Argh.... The switchtest driver is relying on __xn_exec_current to have context switches occur precisely in the mode we want. __xn_exec_adaptive introduce more context switches around which we can not place separate checks for fpu context, so, in short, breaks it badly. Fixing this requires turning the switchtest driver into a skin with its own syscalls. Note the sequence which occurs when a shadowed thread running in secondary mode calls an ioctl for which only an nrt implementation occurs: the thread is hardened to handle the ioctl ioctl_rt is called which returns -ENOSYS the thread is relaxed ioctl_nrt is called It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm syscall made by a thread with a shadow, and in fact seems to result in as bad a result. Is it really what we want? The __xn_exec_current bit resulted in a more lazy behaviour. Also note that, at least when using the posix skin, almost all threads have shadows, and only the priority makes the difference between a really critical thread, and non critical threads with the null priority. So, this will happen all the time. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 19:47 ` Gilles Chanteperdrix @ 2010-04-01 21:13 ` Jan Kiszka 2010-04-01 21:22 ` Philippe Gerum 2010-04-01 21:24 ` Philippe Gerum 2010-04-01 21:50 ` Jan Kiszka 2 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 21:13 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 7254 bytes --] Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>> Philippe Gerum wrote: >>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>> Hi, >>>>> >>>>> Philippe Gerum wrote: >>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>>> connection. >>>>>>> >>>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>> >>>>>>> Daniele Nicolodi wrote: >>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>> >>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>> shipped with xenomai 2.5.1). >>>>>>>> >>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>> >>>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>>> >>>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>>> That is why, the program switches back to primary mode after. >>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>>> for this one. >>>>>> >>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>> >>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>>> both RT and NRT fops entries), I thought there was no automatic >>>>> mode-switching. >>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>> detects that the current request should be processed by the converse >>>> domain, to trigger the switch to primary mode. This is why the adaptive >>>> tag is provided in the first place. >>> The problem is that rtdm does not provide any function to know whether >>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>> Linux thread from a Xenomai one. >>> >>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>> >>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>> index 8677c47..cc0cfe9 100644 >>> --- a/ksrc/skins/rtdm/core.c >>> +++ b/ksrc/skins/rtdm/core.c >>> @@ -423,6 +423,9 @@ do { \ >>> \ >>> if (rtdm_in_rt_context()) \ >>> ret = ops->operation##_rt(context, user_info, args); \ >>> + else if (xnshadow_thread(user_info) != NULL && \ >>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>> + ret = -ENOSYS; \ >>> else \ >>> ret = ops->operation##_nrt(context, user_info, args); \ >>> \ >> No, this would be a half-working kludge. But I think you have pinpointed >> a more general issue with RTDM: syscalls should be tagged as both >> adaptive and conforming, instead of bearing the __xn_exec_current bit. >> Actually, we do want the current domain to change when it is not the >> most appropriate, which __xn_exec_current prevents so far. >> >> What we rather want is to have shadows migrating to primary mode when >> running rtdm_ioctl, since this is the preferred mode of operation for >> Xenomai threads, so that ioctl_rt is always invoked first when present, >> giving an opportunity to forward the request to secondary mode by >> returning -ENOSYS. Conforming calls always enforce the preferred runtime >> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >> That logic applies to all RTDM syscalls actually. >> >> __xn_exec_current allows application code to infer that the RTDM driver >> might behave differently depending on the current runtime mode of the >> calling thread, which is very much error-prone, and likely not what was >> envisioned initially. > > Argh.... The switchtest driver is relying on __xn_exec_current to have > context switches occur precisely in the mode we want. __xn_exec_adaptive > introduce more context switches around which we can not place separate > checks for fpu context, so, in short, breaks it badly. Fixing this > requires turning the switchtest driver into a skin with its own syscalls. > > Note the sequence which occurs when a shadowed thread running in > secondary mode calls an ioctl for which only an nrt implementation occurs: > the thread is hardened to handle the ioctl > ioctl_rt is called which returns -ENOSYS > the thread is relaxed > ioctl_nrt is called > > It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm > syscall made by a thread with a shadow, and in fact seems to result in > as bad a result. Is it really what we want? The __xn_exec_current bit > resulted in a more lazy behaviour. > > Also note that, at least when using the posix skin, almost all threads > have shadows, and only the priority makes the difference between a > really critical thread, and non critical threads with the null priority. > So, this will happen all the time. Right. Actually, we only need the conforming property for the (fairly rare) case that a service is provided in both flavors. And if such a service is hidden behind a single IOCTL command, it's even not possible to detect this at RTDM level. We do need help from the driver or its user space library, or we need to give them the tools to do the adaptive switch themselves. So three options: - Implement adaptive switching inside RTDM o For all major functions != ioctl, we need to check for a shadow thread and the availability of an RT handler => switch o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace to indicate the availability of an RT handler. This comes at the risk of colliding with existing drivers that do not use the standard IOCTL encoding scheme. - Push adaptive switching into the driver o That means providing the information if the caller could be switched to RT context. - Push adaptive switching into the helper library o That means exporting a service that performs a switch if the caller is switchable, but currently relaxed. The second option is the least invasive one, I think. The first one is most transparent, but also more fragile and complex than the rest. Three is likely not Philippe's favorite as it would introduce yet another explicit mode switching mechanism. Opinions? Other ideas? Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:13 ` Jan Kiszka @ 2010-04-01 21:22 ` Philippe Gerum 2010-04-01 21:26 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-01 21:22 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Philippe Gerum wrote: > >> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > >>> Philippe Gerum wrote: > >>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >>>>> Hi, > >>>>> > >>>>> Philippe Gerum wrote: > >>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Sorry for answering so late. I took a few days off far from any internet > >>>>>>> connection. > >>>>>>> > >>>>>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>>>>> interest. I have not read all of them yet. However, I am beginning by > >>>>>>> this one (which seems unanswered). The answer is quick and easy :) > >>>>>>> > >>>>>>> Daniele Nicolodi wrote: > >>>>>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>>>>> > >>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>>>>> shipped with xenomai 2.5.1). > >>>>>>>> > >>>>>>>> I do not understand why we have to set the primary mode at every > >>>>>>>> iteration, when we set it before for the task (line 380). > >>>>>>>> > >>>>>>>> Is it because the dump_function() uses system calls that can make the > >>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>>>>> > >>>>>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>>>>> That is why, the program switches back to primary mode after. > >>>>>> This is wrong. The Xenomai core will switch your real-time thread to > >>>>>> primary mode automatically when running a4l_insn* calls that end up > >>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>>>>> for this one. > >>>>>> > >>>>> I don't understand. I thought that rt_dev_ioctl() triggered an > >>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". > >>>>> > >>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >>>>> both RT and NRT fops entries), I thought there was no automatic > >>>>> mode-switching. > >>>> The point is that your ioctl_nrt handler should return -ENOSYS when it > >>>> detects that the current request should be processed by the converse > >>>> domain, to trigger the switch to primary mode. This is why the adaptive > >>>> tag is provided in the first place. > >>> The problem is that rtdm does not provide any function to know whether > >>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us > >>> whether the thread is RT or not. If it is NRT, we cannot distinguish a > >>> Linux thread from a Xenomai one. > >>> > >>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > >>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: > >>> > >>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > >>> index 8677c47..cc0cfe9 100644 > >>> --- a/ksrc/skins/rtdm/core.c > >>> +++ b/ksrc/skins/rtdm/core.c > >>> @@ -423,6 +423,9 @@ do { \ > >>> \ > >>> if (rtdm_in_rt_context()) \ > >>> ret = ops->operation##_rt(context, user_info, args); \ > >>> + else if (xnshadow_thread(user_info) != NULL && \ > >>> + ops->operation##_rt != (void *)rtdm_no_support) \ > >>> + ret = -ENOSYS; \ > >>> else \ > >>> ret = ops->operation##_nrt(context, user_info, args); \ > >>> \ > >> No, this would be a half-working kludge. But I think you have pinpointed > >> a more general issue with RTDM: syscalls should be tagged as both > >> adaptive and conforming, instead of bearing the __xn_exec_current bit. > >> Actually, we do want the current domain to change when it is not the > >> most appropriate, which __xn_exec_current prevents so far. > >> > >> What we rather want is to have shadows migrating to primary mode when > >> running rtdm_ioctl, since this is the preferred mode of operation for > >> Xenomai threads, so that ioctl_rt is always invoked first when present, > >> giving an opportunity to forward the request to secondary mode by > >> returning -ENOSYS. Conforming calls always enforce the preferred runtime > >> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > >> That logic applies to all RTDM syscalls actually. > >> > >> __xn_exec_current allows application code to infer that the RTDM driver > >> might behave differently depending on the current runtime mode of the > >> calling thread, which is very much error-prone, and likely not what was > >> envisioned initially. > > > > Argh.... The switchtest driver is relying on __xn_exec_current to have > > context switches occur precisely in the mode we want. __xn_exec_adaptive > > introduce more context switches around which we can not place separate > > checks for fpu context, so, in short, breaks it badly. Fixing this > > requires turning the switchtest driver into a skin with its own syscalls. > > > > Note the sequence which occurs when a shadowed thread running in > > secondary mode calls an ioctl for which only an nrt implementation occurs: > > the thread is hardened to handle the ioctl > > ioctl_rt is called which returns -ENOSYS > > the thread is relaxed > > ioctl_nrt is called > > > > It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm > > syscall made by a thread with a shadow, and in fact seems to result in > > as bad a result. Is it really what we want? The __xn_exec_current bit > > resulted in a more lazy behaviour. > > > > Also note that, at least when using the posix skin, almost all threads > > have shadows, and only the priority makes the difference between a > > really critical thread, and non critical threads with the null priority. > > So, this will happen all the time. > > Right. Actually, we only need the conforming property for the (fairly > rare) case that a service is provided in both flavors. Wrong. You want conforming because real-time is the preferred mode of operations for real-time threads. > And if such a > service is hidden behind a single IOCTL command, it's even not possible > to detect this at RTDM level. We do need help from the driver or its > user space library, or we need to give them the tools to do the adaptive > switch themselves. > > So three options: > - Implement adaptive switching inside RTDM > o For all major functions != ioctl, we need to check for a shadow > thread and the availability of an RT handler => switch > o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace > to indicate the availability of an RT handler. This comes at the > risk of colliding with existing drivers that do not use the > standard IOCTL encoding scheme. > - Push adaptive switching into the driver > o That means providing the information if the caller could be > switched to RT context. > - Push adaptive switching into the helper library > o That means exporting a service that performs a switch if the > caller is switchable, but currently relaxed. > > The second option is the least invasive one, I think. The first one is > most transparent, but also more fragile and complex than the rest. Three > is likely not Philippe's favorite as it would introduce yet another > explicit mode switching mechanism. > > Opinions? Other ideas? > > Jan > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:22 ` Philippe Gerum @ 2010-04-01 21:26 ` Jan Kiszka 2010-04-01 21:31 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 21:26 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 8064 bytes --] Philippe Gerum wrote: > On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Philippe Gerum wrote: >>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>>>> Philippe Gerum wrote: >>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Philippe Gerum wrote: >>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>>>>> connection. >>>>>>>>> >>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>>>> >>>>>>>>> Daniele Nicolodi wrote: >>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>>>> >>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>>>> shipped with xenomai 2.5.1). >>>>>>>>>> >>>>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>>>> >>>>>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>>>>> >>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>>>>> That is why, the program switches back to primary mode after. >>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>>>>> for this one. >>>>>>>> >>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>>>> >>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>>>>> both RT and NRT fops entries), I thought there was no automatic >>>>>>> mode-switching. >>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>>>> detects that the current request should be processed by the converse >>>>>> domain, to trigger the switch to primary mode. This is why the adaptive >>>>>> tag is provided in the first place. >>>>> The problem is that rtdm does not provide any function to know whether >>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>>>> Linux thread from a Xenomai one. >>>>> >>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>>>> >>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>>>> index 8677c47..cc0cfe9 100644 >>>>> --- a/ksrc/skins/rtdm/core.c >>>>> +++ b/ksrc/skins/rtdm/core.c >>>>> @@ -423,6 +423,9 @@ do { \ >>>>> \ >>>>> if (rtdm_in_rt_context()) \ >>>>> ret = ops->operation##_rt(context, user_info, args); \ >>>>> + else if (xnshadow_thread(user_info) != NULL && \ >>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>>>> + ret = -ENOSYS; \ >>>>> else \ >>>>> ret = ops->operation##_nrt(context, user_info, args); \ >>>>> \ >>>> No, this would be a half-working kludge. But I think you have pinpointed >>>> a more general issue with RTDM: syscalls should be tagged as both >>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. >>>> Actually, we do want the current domain to change when it is not the >>>> most appropriate, which __xn_exec_current prevents so far. >>>> >>>> What we rather want is to have shadows migrating to primary mode when >>>> running rtdm_ioctl, since this is the preferred mode of operation for >>>> Xenomai threads, so that ioctl_rt is always invoked first when present, >>>> giving an opportunity to forward the request to secondary mode by >>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime >>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >>>> That logic applies to all RTDM syscalls actually. >>>> >>>> __xn_exec_current allows application code to infer that the RTDM driver >>>> might behave differently depending on the current runtime mode of the >>>> calling thread, which is very much error-prone, and likely not what was >>>> envisioned initially. >>> Argh.... The switchtest driver is relying on __xn_exec_current to have >>> context switches occur precisely in the mode we want. __xn_exec_adaptive >>> introduce more context switches around which we can not place separate >>> checks for fpu context, so, in short, breaks it badly. Fixing this >>> requires turning the switchtest driver into a skin with its own syscalls. >>> >>> Note the sequence which occurs when a shadowed thread running in >>> secondary mode calls an ioctl for which only an nrt implementation occurs: >>> the thread is hardened to handle the ioctl >>> ioctl_rt is called which returns -ENOSYS >>> the thread is relaxed >>> ioctl_nrt is called >>> >>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm >>> syscall made by a thread with a shadow, and in fact seems to result in >>> as bad a result. Is it really what we want? The __xn_exec_current bit >>> resulted in a more lazy behaviour. >>> >>> Also note that, at least when using the posix skin, almost all threads >>> have shadows, and only the priority makes the difference between a >>> really critical thread, and non critical threads with the null priority. >>> So, this will happen all the time. >> Right. Actually, we only need the conforming property for the (fairly >> rare) case that a service is provided in both flavors. > > Wrong. You want conforming because real-time is the preferred mode of > operations for real-time threads. Sorry, wrong as well. :) Setup/reconfiguration phases happening over already shadowed threads can suffer significantly when playing ping-pong via mode switches. That's why threads stay in secondary mode after their first Linux syscall and are not immediately switched back. Jan > >> And if such a >> service is hidden behind a single IOCTL command, it's even not possible >> to detect this at RTDM level. We do need help from the driver or its >> user space library, or we need to give them the tools to do the adaptive >> switch themselves. >> >> So three options: >> - Implement adaptive switching inside RTDM >> o For all major functions != ioctl, we need to check for a shadow >> thread and the availability of an RT handler => switch >> o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace >> to indicate the availability of an RT handler. This comes at the >> risk of colliding with existing drivers that do not use the >> standard IOCTL encoding scheme. >> - Push adaptive switching into the driver >> o That means providing the information if the caller could be >> switched to RT context. >> - Push adaptive switching into the helper library >> o That means exporting a service that performs a switch if the >> caller is switchable, but currently relaxed. >> >> The second option is the least invasive one, I think. The first one is >> most transparent, but also more fragile and complex than the rest. Three >> is likely not Philippe's favorite as it would introduce yet another >> explicit mode switching mechanism. >> >> Opinions? Other ideas? >> >> Jan >> > > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:26 ` Jan Kiszka @ 2010-04-01 21:31 ` Philippe Gerum 2010-04-01 21:36 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-01 21:31 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: > >> Gilles Chanteperdrix wrote: > >>> Philippe Gerum wrote: > >>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > >>>>> Philippe Gerum wrote: > >>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Philippe Gerum wrote: > >>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Sorry for answering so late. I took a few days off far from any internet > >>>>>>>>> connection. > >>>>>>>>> > >>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>>>>>>> interest. I have not read all of them yet. However, I am beginning by > >>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) > >>>>>>>>> > >>>>>>>>> Daniele Nicolodi wrote: > >>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>>>>>>> > >>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>>>>>>> shipped with xenomai 2.5.1). > >>>>>>>>>> > >>>>>>>>>> I do not understand why we have to set the primary mode at every > >>>>>>>>>> iteration, when we set it before for the task (line 380). > >>>>>>>>>> > >>>>>>>>>> Is it because the dump_function() uses system calls that can make the > >>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>>>>>>> > >>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>>>>>>> That is why, the program switches back to primary mode after. > >>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to > >>>>>>>> primary mode automatically when running a4l_insn* calls that end up > >>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>>>>>>> for this one. > >>>>>>>> > >>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an > >>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". > >>>>>>> > >>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >>>>>>> both RT and NRT fops entries), I thought there was no automatic > >>>>>>> mode-switching. > >>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it > >>>>>> detects that the current request should be processed by the converse > >>>>>> domain, to trigger the switch to primary mode. This is why the adaptive > >>>>>> tag is provided in the first place. > >>>>> The problem is that rtdm does not provide any function to know whether > >>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us > >>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a > >>>>> Linux thread from a Xenomai one. > >>>>> > >>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > >>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: > >>>>> > >>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > >>>>> index 8677c47..cc0cfe9 100644 > >>>>> --- a/ksrc/skins/rtdm/core.c > >>>>> +++ b/ksrc/skins/rtdm/core.c > >>>>> @@ -423,6 +423,9 @@ do { \ > >>>>> \ > >>>>> if (rtdm_in_rt_context()) \ > >>>>> ret = ops->operation##_rt(context, user_info, args); \ > >>>>> + else if (xnshadow_thread(user_info) != NULL && \ > >>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ > >>>>> + ret = -ENOSYS; \ > >>>>> else \ > >>>>> ret = ops->operation##_nrt(context, user_info, args); \ > >>>>> \ > >>>> No, this would be a half-working kludge. But I think you have pinpointed > >>>> a more general issue with RTDM: syscalls should be tagged as both > >>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. > >>>> Actually, we do want the current domain to change when it is not the > >>>> most appropriate, which __xn_exec_current prevents so far. > >>>> > >>>> What we rather want is to have shadows migrating to primary mode when > >>>> running rtdm_ioctl, since this is the preferred mode of operation for > >>>> Xenomai threads, so that ioctl_rt is always invoked first when present, > >>>> giving an opportunity to forward the request to secondary mode by > >>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime > >>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > >>>> That logic applies to all RTDM syscalls actually. > >>>> > >>>> __xn_exec_current allows application code to infer that the RTDM driver > >>>> might behave differently depending on the current runtime mode of the > >>>> calling thread, which is very much error-prone, and likely not what was > >>>> envisioned initially. > >>> Argh.... The switchtest driver is relying on __xn_exec_current to have > >>> context switches occur precisely in the mode we want. __xn_exec_adaptive > >>> introduce more context switches around which we can not place separate > >>> checks for fpu context, so, in short, breaks it badly. Fixing this > >>> requires turning the switchtest driver into a skin with its own syscalls. > >>> > >>> Note the sequence which occurs when a shadowed thread running in > >>> secondary mode calls an ioctl for which only an nrt implementation occurs: > >>> the thread is hardened to handle the ioctl > >>> ioctl_rt is called which returns -ENOSYS > >>> the thread is relaxed > >>> ioctl_nrt is called > >>> > >>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm > >>> syscall made by a thread with a shadow, and in fact seems to result in > >>> as bad a result. Is it really what we want? The __xn_exec_current bit > >>> resulted in a more lazy behaviour. > >>> > >>> Also note that, at least when using the posix skin, almost all threads > >>> have shadows, and only the priority makes the difference between a > >>> really critical thread, and non critical threads with the null priority. > >>> So, this will happen all the time. > >> Right. Actually, we only need the conforming property for the (fairly > >> rare) case that a service is provided in both flavors. > > > > Wrong. You want conforming because real-time is the preferred mode of > > operations for real-time threads. > > Sorry, wrong as well. :) > > Setup/reconfiguration phases happening over already shadowed threads can > suffer significantly when playing ping-pong via mode switches. That's > why threads stay in secondary mode after their first Linux syscall and > are not immediately switched back. I decided to implement lazy switch in that case because it made sense not to add overhead when it is not needed. The situation you describe is a code that actually cares for an extra switch at the expense of a proper design, by imposing a lot of mode switches in tight loops. Please fix the app, not the core, really. > > Jan > > > > >> And if such a > >> service is hidden behind a single IOCTL command, it's even not possible > >> to detect this at RTDM level. We do need help from the driver or its > >> user space library, or we need to give them the tools to do the adaptive > >> switch themselves. > >> > >> So three options: > >> - Implement adaptive switching inside RTDM > >> o For all major functions != ioctl, we need to check for a shadow > >> thread and the availability of an RT handler => switch > >> o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace > >> to indicate the availability of an RT handler. This comes at the > >> risk of colliding with existing drivers that do not use the > >> standard IOCTL encoding scheme. > >> - Push adaptive switching into the driver > >> o That means providing the information if the caller could be > >> switched to RT context. > >> - Push adaptive switching into the helper library > >> o That means exporting a service that performs a switch if the > >> caller is switchable, but currently relaxed. > >> > >> The second option is the least invasive one, I think. The first one is > >> most transparent, but also more fragile and complex than the rest. Three > >> is likely not Philippe's favorite as it would introduce yet another > >> explicit mode switching mechanism. > >> > >> Opinions? Other ideas? > >> > >> Jan > >> > > > > > > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:31 ` Philippe Gerum @ 2010-04-01 21:36 ` Jan Kiszka 2010-04-01 21:48 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 21:36 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 7729 bytes --] Philippe Gerum wrote: > On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Philippe Gerum wrote: >>>>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>>>>>> Philippe Gerum wrote: >>>>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Philippe Gerum wrote: >>>>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>>>>>>> connection. >>>>>>>>>>> >>>>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>>>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>>>>>> >>>>>>>>>>> Daniele Nicolodi wrote: >>>>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>>>>>> shipped with xenomai 2.5.1). >>>>>>>>>>>> >>>>>>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>>>>>> >>>>>>>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>>>>>>> >>>>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>>>>>>> That is why, the program switches back to primary mode after. >>>>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>>>>>>> for this one. >>>>>>>>>> >>>>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>>>>>> >>>>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>>>>>>> both RT and NRT fops entries), I thought there was no automatic >>>>>>>>> mode-switching. >>>>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>>>>>> detects that the current request should be processed by the converse >>>>>>>> domain, to trigger the switch to primary mode. This is why the adaptive >>>>>>>> tag is provided in the first place. >>>>>>> The problem is that rtdm does not provide any function to know whether >>>>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >>>>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>>>>>> Linux thread from a Xenomai one. >>>>>>> >>>>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >>>>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>>>>>> >>>>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>>>>>> index 8677c47..cc0cfe9 100644 >>>>>>> --- a/ksrc/skins/rtdm/core.c >>>>>>> +++ b/ksrc/skins/rtdm/core.c >>>>>>> @@ -423,6 +423,9 @@ do { \ >>>>>>> \ >>>>>>> if (rtdm_in_rt_context()) \ >>>>>>> ret = ops->operation##_rt(context, user_info, args); \ >>>>>>> + else if (xnshadow_thread(user_info) != NULL && \ >>>>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>>>>>> + ret = -ENOSYS; \ >>>>>>> else \ >>>>>>> ret = ops->operation##_nrt(context, user_info, args); \ >>>>>>> \ >>>>>> No, this would be a half-working kludge. But I think you have pinpointed >>>>>> a more general issue with RTDM: syscalls should be tagged as both >>>>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. >>>>>> Actually, we do want the current domain to change when it is not the >>>>>> most appropriate, which __xn_exec_current prevents so far. >>>>>> >>>>>> What we rather want is to have shadows migrating to primary mode when >>>>>> running rtdm_ioctl, since this is the preferred mode of operation for >>>>>> Xenomai threads, so that ioctl_rt is always invoked first when present, >>>>>> giving an opportunity to forward the request to secondary mode by >>>>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime >>>>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >>>>>> That logic applies to all RTDM syscalls actually. >>>>>> >>>>>> __xn_exec_current allows application code to infer that the RTDM driver >>>>>> might behave differently depending on the current runtime mode of the >>>>>> calling thread, which is very much error-prone, and likely not what was >>>>>> envisioned initially. >>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have >>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive >>>>> introduce more context switches around which we can not place separate >>>>> checks for fpu context, so, in short, breaks it badly. Fixing this >>>>> requires turning the switchtest driver into a skin with its own syscalls. >>>>> >>>>> Note the sequence which occurs when a shadowed thread running in >>>>> secondary mode calls an ioctl for which only an nrt implementation occurs: >>>>> the thread is hardened to handle the ioctl >>>>> ioctl_rt is called which returns -ENOSYS >>>>> the thread is relaxed >>>>> ioctl_nrt is called >>>>> >>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm >>>>> syscall made by a thread with a shadow, and in fact seems to result in >>>>> as bad a result. Is it really what we want? The __xn_exec_current bit >>>>> resulted in a more lazy behaviour. >>>>> >>>>> Also note that, at least when using the posix skin, almost all threads >>>>> have shadows, and only the priority makes the difference between a >>>>> really critical thread, and non critical threads with the null priority. >>>>> So, this will happen all the time. >>>> Right. Actually, we only need the conforming property for the (fairly >>>> rare) case that a service is provided in both flavors. >>> Wrong. You want conforming because real-time is the preferred mode of >>> operations for real-time threads. >> Sorry, wrong as well. :) >> >> Setup/reconfiguration phases happening over already shadowed threads can >> suffer significantly when playing ping-pong via mode switches. That's >> why threads stay in secondary mode after their first Linux syscall and >> are not immediately switched back. > > I decided to implement lazy switch in that case because it made sense > not to add overhead when it is not needed. The situation you describe is > a code that actually cares for an extra switch at the expense of a > proper design, by imposing a lot of mode switches in tight loops. Please > fix the app, not the core, really. You still assume that there aren't many non-RT services provided by an RTDM driver. That's true - for some drivers. It's totally wrong for others. RTDM simply doesn't know this. The core was designed for flexibility - as it has to deal with all those kinds of drivers. So the best decision here is to give control back to the driver, not try to be overly clever at the most generic point in RTDM. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:36 ` Jan Kiszka @ 2010-04-01 21:48 ` Philippe Gerum 2010-04-01 21:54 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-01 21:48 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai On Thu, 2010-04-01 at 23:36 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote: > >> Philippe Gerum wrote: > >>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: > >>>> Gilles Chanteperdrix wrote: > >>>>> Philippe Gerum wrote: > >>>>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > >>>>>>> Philippe Gerum wrote: > >>>>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Philippe Gerum wrote: > >>>>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Sorry for answering so late. I took a few days off far from any internet > >>>>>>>>>>> connection. > >>>>>>>>>>> > >>>>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>>>>>>>>> interest. I have not read all of them yet. However, I am beginning by > >>>>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) > >>>>>>>>>>> > >>>>>>>>>>> Daniele Nicolodi wrote: > >>>>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>>>>>>>>> > >>>>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>>>>>>>>> shipped with xenomai 2.5.1). > >>>>>>>>>>>> > >>>>>>>>>>>> I do not understand why we have to set the primary mode at every > >>>>>>>>>>>> iteration, when we set it before for the task (line 380). > >>>>>>>>>>>> > >>>>>>>>>>>> Is it because the dump_function() uses system calls that can make the > >>>>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>>>>>>>>> > >>>>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>>>>>>>>> That is why, the program switches back to primary mode after. > >>>>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to > >>>>>>>>>> primary mode automatically when running a4l_insn* calls that end up > >>>>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>>>>>>>>> for this one. > >>>>>>>>>> > >>>>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an > >>>>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >>>>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". > >>>>>>>>> > >>>>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >>>>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >>>>>>>>> both RT and NRT fops entries), I thought there was no automatic > >>>>>>>>> mode-switching. > >>>>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it > >>>>>>>> detects that the current request should be processed by the converse > >>>>>>>> domain, to trigger the switch to primary mode. This is why the adaptive > >>>>>>>> tag is provided in the first place. > >>>>>>> The problem is that rtdm does not provide any function to know whether > >>>>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us > >>>>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a > >>>>>>> Linux thread from a Xenomai one. > >>>>>>> > >>>>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > >>>>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: > >>>>>>> > >>>>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > >>>>>>> index 8677c47..cc0cfe9 100644 > >>>>>>> --- a/ksrc/skins/rtdm/core.c > >>>>>>> +++ b/ksrc/skins/rtdm/core.c > >>>>>>> @@ -423,6 +423,9 @@ do { \ > >>>>>>> \ > >>>>>>> if (rtdm_in_rt_context()) \ > >>>>>>> ret = ops->operation##_rt(context, user_info, args); \ > >>>>>>> + else if (xnshadow_thread(user_info) != NULL && \ > >>>>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ > >>>>>>> + ret = -ENOSYS; \ > >>>>>>> else \ > >>>>>>> ret = ops->operation##_nrt(context, user_info, args); \ > >>>>>>> \ > >>>>>> No, this would be a half-working kludge. But I think you have pinpointed > >>>>>> a more general issue with RTDM: syscalls should be tagged as both > >>>>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. > >>>>>> Actually, we do want the current domain to change when it is not the > >>>>>> most appropriate, which __xn_exec_current prevents so far. > >>>>>> > >>>>>> What we rather want is to have shadows migrating to primary mode when > >>>>>> running rtdm_ioctl, since this is the preferred mode of operation for > >>>>>> Xenomai threads, so that ioctl_rt is always invoked first when present, > >>>>>> giving an opportunity to forward the request to secondary mode by > >>>>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime > >>>>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > >>>>>> That logic applies to all RTDM syscalls actually. > >>>>>> > >>>>>> __xn_exec_current allows application code to infer that the RTDM driver > >>>>>> might behave differently depending on the current runtime mode of the > >>>>>> calling thread, which is very much error-prone, and likely not what was > >>>>>> envisioned initially. > >>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have > >>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive > >>>>> introduce more context switches around which we can not place separate > >>>>> checks for fpu context, so, in short, breaks it badly. Fixing this > >>>>> requires turning the switchtest driver into a skin with its own syscalls. > >>>>> > >>>>> Note the sequence which occurs when a shadowed thread running in > >>>>> secondary mode calls an ioctl for which only an nrt implementation occurs: > >>>>> the thread is hardened to handle the ioctl > >>>>> ioctl_rt is called which returns -ENOSYS > >>>>> the thread is relaxed > >>>>> ioctl_nrt is called > >>>>> > >>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm > >>>>> syscall made by a thread with a shadow, and in fact seems to result in > >>>>> as bad a result. Is it really what we want? The __xn_exec_current bit > >>>>> resulted in a more lazy behaviour. > >>>>> > >>>>> Also note that, at least when using the posix skin, almost all threads > >>>>> have shadows, and only the priority makes the difference between a > >>>>> really critical thread, and non critical threads with the null priority. > >>>>> So, this will happen all the time. > >>>> Right. Actually, we only need the conforming property for the (fairly > >>>> rare) case that a service is provided in both flavors. > >>> Wrong. You want conforming because real-time is the preferred mode of > >>> operations for real-time threads. > >> Sorry, wrong as well. :) > >> > >> Setup/reconfiguration phases happening over already shadowed threads can > >> suffer significantly when playing ping-pong via mode switches. That's > >> why threads stay in secondary mode after their first Linux syscall and > >> are not immediately switched back. > > > > I decided to implement lazy switch in that case because it made sense > > not to add overhead when it is not needed. The situation you describe is > > a code that actually cares for an extra switch at the expense of a > > proper design, by imposing a lot of mode switches in tight loops. Please > > fix the app, not the core, really. > > You still assume that there aren't many non-RT services provided by an > RTDM driver. That's true - for some drivers. It's totally wrong for > others. RTDM simply doesn't know this. > > The core was designed for flexibility - as it has to deal with all those > kinds of drivers. So the best decision here is to give control back to > the driver, not try to be overly clever at the most generic point in RTDM. > It's not about being clever, /me can't do that magic anyway. But, this is about ensuring that people, who don't necessarily understand how the innards of the underlying co-kernel work, do benefit from the principle of least surprise. And using conforming calls for drivers - which may expose a given syscall to different kind of threads (e.g. Analogy) - is, at least on the paper, the best option. The bottom line for me, is that T_PRIMARY, as a user-space visible "feature" should be dropped at some point, and never ever considered as a way to fix the RTDM syscall issue anymore. I don't mind saving an extra-context switch even in what I think should be _rare_ cases, but this has to be done in a way that does not introduce the same kind of misunderstanding the eager mode switching allowed by rt_task_set_mode() did in the past. Really, I'm convinced that an awful lot of people are currently running under-performing at best, or even broken applications today, because of that, thing. > Jan > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:48 ` Philippe Gerum @ 2010-04-01 21:54 ` Jan Kiszka 2010-04-01 22:00 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 21:54 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 9478 bytes --] Philippe Gerum wrote: > On Thu, 2010-04-01 at 23:36 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: >>>>>> Gilles Chanteperdrix wrote: >>>>>>> Philippe Gerum wrote: >>>>>>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: >>>>>>>>> Philippe Gerum wrote: >>>>>>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Philippe Gerum wrote: >>>>>>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for answering so late. I took a few days off far from any internet >>>>>>>>>>>>> connection. >>>>>>>>>>>>> >>>>>>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your >>>>>>>>>>>>> interest. I have not read all of them yet. However, I am beginning by >>>>>>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) >>>>>>>>>>>>> >>>>>>>>>>>>> Daniele Nicolodi wrote: >>>>>>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function >>>>>>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code >>>>>>>>>>>>>> shipped with xenomai 2.5.1). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not understand why we have to set the primary mode at every >>>>>>>>>>>>>> iteration, when we set it before for the task (line 380). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it because the dump_function() uses system calls that can make the >>>>>>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? >>>>>>>>>>>>>> >>>>>>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. >>>>>>>>>>>>> That is why, the program switches back to primary mode after. >>>>>>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to >>>>>>>>>>>> primary mode automatically when running a4l_insn* calls that end up >>>>>>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point >>>>>>>>>>>> for this one. >>>>>>>>>>>> >>>>>>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an >>>>>>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared >>>>>>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". >>>>>>>>>>> >>>>>>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will >>>>>>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares >>>>>>>>>>> both RT and NRT fops entries), I thought there was no automatic >>>>>>>>>>> mode-switching. >>>>>>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it >>>>>>>>>> detects that the current request should be processed by the converse >>>>>>>>>> domain, to trigger the switch to primary mode. This is why the adaptive >>>>>>>>>> tag is provided in the first place. >>>>>>>>> The problem is that rtdm does not provide any function to know whether >>>>>>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us >>>>>>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a >>>>>>>>> Linux thread from a Xenomai one. >>>>>>>>> >>>>>>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we >>>>>>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: >>>>>>>>> >>>>>>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c >>>>>>>>> index 8677c47..cc0cfe9 100644 >>>>>>>>> --- a/ksrc/skins/rtdm/core.c >>>>>>>>> +++ b/ksrc/skins/rtdm/core.c >>>>>>>>> @@ -423,6 +423,9 @@ do { \ >>>>>>>>> \ >>>>>>>>> if (rtdm_in_rt_context()) \ >>>>>>>>> ret = ops->operation##_rt(context, user_info, args); \ >>>>>>>>> + else if (xnshadow_thread(user_info) != NULL && \ >>>>>>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ >>>>>>>>> + ret = -ENOSYS; \ >>>>>>>>> else \ >>>>>>>>> ret = ops->operation##_nrt(context, user_info, args); \ >>>>>>>>> \ >>>>>>>> No, this would be a half-working kludge. But I think you have pinpointed >>>>>>>> a more general issue with RTDM: syscalls should be tagged as both >>>>>>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. >>>>>>>> Actually, we do want the current domain to change when it is not the >>>>>>>> most appropriate, which __xn_exec_current prevents so far. >>>>>>>> >>>>>>>> What we rather want is to have shadows migrating to primary mode when >>>>>>>> running rtdm_ioctl, since this is the preferred mode of operation for >>>>>>>> Xenomai threads, so that ioctl_rt is always invoked first when present, >>>>>>>> giving an opportunity to forward the request to secondary mode by >>>>>>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime >>>>>>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. >>>>>>>> That logic applies to all RTDM syscalls actually. >>>>>>>> >>>>>>>> __xn_exec_current allows application code to infer that the RTDM driver >>>>>>>> might behave differently depending on the current runtime mode of the >>>>>>>> calling thread, which is very much error-prone, and likely not what was >>>>>>>> envisioned initially. >>>>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have >>>>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive >>>>>>> introduce more context switches around which we can not place separate >>>>>>> checks for fpu context, so, in short, breaks it badly. Fixing this >>>>>>> requires turning the switchtest driver into a skin with its own syscalls. >>>>>>> >>>>>>> Note the sequence which occurs when a shadowed thread running in >>>>>>> secondary mode calls an ioctl for which only an nrt implementation occurs: >>>>>>> the thread is hardened to handle the ioctl >>>>>>> ioctl_rt is called which returns -ENOSYS >>>>>>> the thread is relaxed >>>>>>> ioctl_nrt is called >>>>>>> >>>>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm >>>>>>> syscall made by a thread with a shadow, and in fact seems to result in >>>>>>> as bad a result. Is it really what we want? The __xn_exec_current bit >>>>>>> resulted in a more lazy behaviour. >>>>>>> >>>>>>> Also note that, at least when using the posix skin, almost all threads >>>>>>> have shadows, and only the priority makes the difference between a >>>>>>> really critical thread, and non critical threads with the null priority. >>>>>>> So, this will happen all the time. >>>>>> Right. Actually, we only need the conforming property for the (fairly >>>>>> rare) case that a service is provided in both flavors. >>>>> Wrong. You want conforming because real-time is the preferred mode of >>>>> operations for real-time threads. >>>> Sorry, wrong as well. :) >>>> >>>> Setup/reconfiguration phases happening over already shadowed threads can >>>> suffer significantly when playing ping-pong via mode switches. That's >>>> why threads stay in secondary mode after their first Linux syscall and >>>> are not immediately switched back. >>> I decided to implement lazy switch in that case because it made sense >>> not to add overhead when it is not needed. The situation you describe is >>> a code that actually cares for an extra switch at the expense of a >>> proper design, by imposing a lot of mode switches in tight loops. Please >>> fix the app, not the core, really. >> You still assume that there aren't many non-RT services provided by an >> RTDM driver. That's true - for some drivers. It's totally wrong for >> others. RTDM simply doesn't know this. >> >> The core was designed for flexibility - as it has to deal with all those >> kinds of drivers. So the best decision here is to give control back to >> the driver, not try to be overly clever at the most generic point in RTDM. >> > > It's not about being clever, /me can't do that magic anyway. But, this > is about ensuring that people, who don't necessarily understand how the > innards of the underlying co-kernel work, do benefit from the principle > of least surprise. And using conforming calls for drivers - which may > expose a given syscall to different kind of threads (e.g. Analogy) - is, > at least on the paper, the best option. > > The bottom line for me, is that T_PRIMARY, as a user-space visible > "feature" should be dropped at some point, and never ever considered as > a way to fix the RTDM syscall issue anymore. I don't mind saving an > extra-context switch even in what I think should be _rare_ cases, but > this has to be done in a way that does not introduce the same kind of > misunderstanding the eager mode switching allowed by rt_task_set_mode() > did in the past. > > Really, I'm convinced that an awful lot of people are currently running > under-performing at best, or even broken applications today, because of > that, thing. We are not discussing T_PRIMARY here. We are discussing something like an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that actually want to provide Ianus-like services. I'm fairly convinced now that solving that corner-case via conforming syscalls for _all_ RTDM services, thus _all_ drivers, is the wrong path. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:54 ` Jan Kiszka @ 2010-04-01 22:00 ` Philippe Gerum 2010-04-01 22:07 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-01 22:00 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Thu, 2010-04-01 at 23:36 +0200, Jan Kiszka wrote: > >> Philippe Gerum wrote: > >>> On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote: > >>>> Philippe Gerum wrote: > >>>>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote: > >>>>>> Gilles Chanteperdrix wrote: > >>>>>>> Philippe Gerum wrote: > >>>>>>>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > >>>>>>>>> Philippe Gerum wrote: > >>>>>>>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Philippe Gerum wrote: > >>>>>>>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Sorry for answering so late. I took a few days off far from any internet > >>>>>>>>>>>>> connection. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>>>>>>>>>>> interest. I have not read all of them yet. However, I am beginning by > >>>>>>>>>>>>> this one (which seems unanswered). The answer is quick and easy :) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Daniele Nicolodi wrote: > >>>>>>>>>>>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>>>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>>>>>>>>>>> shipped with xenomai 2.5.1). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I do not understand why we have to set the primary mode at every > >>>>>>>>>>>>>> iteration, when we set it before for the task (line 380). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Is it because the dump_function() uses system calls that can make the > >>>>>>>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>>>>>>>>>>> > >>>>>>>>>>>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>>>>>>>>>>> That is why, the program switches back to primary mode after. > >>>>>>>>>>>> This is wrong. The Xenomai core will switch your real-time thread to > >>>>>>>>>>>> primary mode automatically when running a4l_insn* calls that end up > >>>>>>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>>>>>>>>>>> for this one. > >>>>>>>>>>>> > >>>>>>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an > >>>>>>>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >>>>>>>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive". > >>>>>>>>>>> > >>>>>>>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >>>>>>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >>>>>>>>>>> both RT and NRT fops entries), I thought there was no automatic > >>>>>>>>>>> mode-switching. > >>>>>>>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it > >>>>>>>>>> detects that the current request should be processed by the converse > >>>>>>>>>> domain, to trigger the switch to primary mode. This is why the adaptive > >>>>>>>>>> tag is provided in the first place. > >>>>>>>>> The problem is that rtdm does not provide any function to know whether > >>>>>>>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us > >>>>>>>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a > >>>>>>>>> Linux thread from a Xenomai one. > >>>>>>>>> > >>>>>>>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > >>>>>>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread: > >>>>>>>>> > >>>>>>>>> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > >>>>>>>>> index 8677c47..cc0cfe9 100644 > >>>>>>>>> --- a/ksrc/skins/rtdm/core.c > >>>>>>>>> +++ b/ksrc/skins/rtdm/core.c > >>>>>>>>> @@ -423,6 +423,9 @@ do { \ > >>>>>>>>> \ > >>>>>>>>> if (rtdm_in_rt_context()) \ > >>>>>>>>> ret = ops->operation##_rt(context, user_info, args); \ > >>>>>>>>> + else if (xnshadow_thread(user_info) != NULL && \ > >>>>>>>>> + ops->operation##_rt != (void *)rtdm_no_support) \ > >>>>>>>>> + ret = -ENOSYS; \ > >>>>>>>>> else \ > >>>>>>>>> ret = ops->operation##_nrt(context, user_info, args); \ > >>>>>>>>> \ > >>>>>>>> No, this would be a half-working kludge. But I think you have pinpointed > >>>>>>>> a more general issue with RTDM: syscalls should be tagged as both > >>>>>>>> adaptive and conforming, instead of bearing the __xn_exec_current bit. > >>>>>>>> Actually, we do want the current domain to change when it is not the > >>>>>>>> most appropriate, which __xn_exec_current prevents so far. > >>>>>>>> > >>>>>>>> What we rather want is to have shadows migrating to primary mode when > >>>>>>>> running rtdm_ioctl, since this is the preferred mode of operation for > >>>>>>>> Xenomai threads, so that ioctl_rt is always invoked first when present, > >>>>>>>> giving an opportunity to forward the request to secondary mode by > >>>>>>>> returning -ENOSYS. Conforming calls always enforce the preferred runtime > >>>>>>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > >>>>>>>> That logic applies to all RTDM syscalls actually. > >>>>>>>> > >>>>>>>> __xn_exec_current allows application code to infer that the RTDM driver > >>>>>>>> might behave differently depending on the current runtime mode of the > >>>>>>>> calling thread, which is very much error-prone, and likely not what was > >>>>>>>> envisioned initially. > >>>>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have > >>>>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive > >>>>>>> introduce more context switches around which we can not place separate > >>>>>>> checks for fpu context, so, in short, breaks it badly. Fixing this > >>>>>>> requires turning the switchtest driver into a skin with its own syscalls. > >>>>>>> > >>>>>>> Note the sequence which occurs when a shadowed thread running in > >>>>>>> secondary mode calls an ioctl for which only an nrt implementation occurs: > >>>>>>> the thread is hardened to handle the ioctl > >>>>>>> ioctl_rt is called which returns -ENOSYS > >>>>>>> the thread is relaxed > >>>>>>> ioctl_nrt is called > >>>>>>> > >>>>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm > >>>>>>> syscall made by a thread with a shadow, and in fact seems to result in > >>>>>>> as bad a result. Is it really what we want? The __xn_exec_current bit > >>>>>>> resulted in a more lazy behaviour. > >>>>>>> > >>>>>>> Also note that, at least when using the posix skin, almost all threads > >>>>>>> have shadows, and only the priority makes the difference between a > >>>>>>> really critical thread, and non critical threads with the null priority. > >>>>>>> So, this will happen all the time. > >>>>>> Right. Actually, we only need the conforming property for the (fairly > >>>>>> rare) case that a service is provided in both flavors. > >>>>> Wrong. You want conforming because real-time is the preferred mode of > >>>>> operations for real-time threads. > >>>> Sorry, wrong as well. :) > >>>> > >>>> Setup/reconfiguration phases happening over already shadowed threads can > >>>> suffer significantly when playing ping-pong via mode switches. That's > >>>> why threads stay in secondary mode after their first Linux syscall and > >>>> are not immediately switched back. > >>> I decided to implement lazy switch in that case because it made sense > >>> not to add overhead when it is not needed. The situation you describe is > >>> a code that actually cares for an extra switch at the expense of a > >>> proper design, by imposing a lot of mode switches in tight loops. Please > >>> fix the app, not the core, really. > >> You still assume that there aren't many non-RT services provided by an > >> RTDM driver. That's true - for some drivers. It's totally wrong for > >> others. RTDM simply doesn't know this. > >> > >> The core was designed for flexibility - as it has to deal with all those > >> kinds of drivers. So the best decision here is to give control back to > >> the driver, not try to be overly clever at the most generic point in RTDM. > >> > > > > It's not about being clever, /me can't do that magic anyway. But, this > > is about ensuring that people, who don't necessarily understand how the > > innards of the underlying co-kernel work, do benefit from the principle > > of least surprise. And using conforming calls for drivers - which may > > expose a given syscall to different kind of threads (e.g. Analogy) - is, > > at least on the paper, the best option. > > > > The bottom line for me, is that T_PRIMARY, as a user-space visible > > "feature" should be dropped at some point, and never ever considered as > > a way to fix the RTDM syscall issue anymore. I don't mind saving an > > extra-context switch even in what I think should be _rare_ cases, but > > this has to be done in a way that does not introduce the same kind of > > misunderstanding the eager mode switching allowed by rt_task_set_mode() > > did in the past. > > > > Really, I'm convinced that an awful lot of people are currently running > > under-performing at best, or even broken applications today, because of > > that, thing. > > We are not discussing T_PRIMARY here. We are discussing something like > an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that > actually want to provide Ianus-like services. > Yes, we do discuss of T_PRIMARY in between the lines. > I'm fairly convinced now that solving that corner-case via conforming > syscalls for _all_ RTDM services, thus _all_ drivers, is the wrong path. > > Jan > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 22:00 ` Philippe Gerum @ 2010-04-01 22:07 ` Jan Kiszka 2010-04-01 22:53 ` Gilles Chanteperdrix 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 22:07 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 1154 bytes --] Philippe Gerum wrote: > On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> The bottom line for me, is that T_PRIMARY, as a user-space visible >>> "feature" should be dropped at some point, and never ever considered as >>> a way to fix the RTDM syscall issue anymore. I don't mind saving an >>> extra-context switch even in what I think should be _rare_ cases, but >>> this has to be done in a way that does not introduce the same kind of >>> misunderstanding the eager mode switching allowed by rt_task_set_mode() >>> did in the past. >>> >>> Really, I'm convinced that an awful lot of people are currently running >>> under-performing at best, or even broken applications today, because of >>> that, thing. >> We are not discussing T_PRIMARY here. We are discussing something like >> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that >> actually want to provide Ianus-like services. >> > > Yes, we do discuss of T_PRIMARY in between the lines. > You can take it away, and the rtdm_is_rt_capable-approach would still work, but that without affecting existing designs. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 22:07 ` Jan Kiszka @ 2010-04-01 22:53 ` Gilles Chanteperdrix 2010-04-01 22:58 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-01 22:53 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai Jan Kiszka wrote: > Philippe Gerum wrote: >> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote: >>> Philippe Gerum wrote: >>>> The bottom line for me, is that T_PRIMARY, as a user-space visible >>>> "feature" should be dropped at some point, and never ever considered as >>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an >>>> extra-context switch even in what I think should be _rare_ cases, but >>>> this has to be done in a way that does not introduce the same kind of >>>> misunderstanding the eager mode switching allowed by rt_task_set_mode() >>>> did in the past. >>>> >>>> Really, I'm convinced that an awful lot of people are currently running >>>> under-performing at best, or even broken applications today, because of >>>> that, thing. >>> We are not discussing T_PRIMARY here. We are discussing something like >>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that >>> actually want to provide Ianus-like services. >>> >> Yes, we do discuss of T_PRIMARY in between the lines. >> > > You can take it away, and the rtdm_is_rt_capable-approach would still > work, but that without affecting existing designs. Ok. I almost regret I launched this troll. We have discussed some time with Philippe, and I agree with him that drivers which this change really broke were already broken. The only side-effect is the double switch issue, which, per-se is not that much a trouble in real-world applications. So what I propose is a special RTDM driver flag that would somehow fix the issue for the switchtest driver, and would only be used by that driver and not exported in the rtdm headers, and of course not documented. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 22:53 ` Gilles Chanteperdrix @ 2010-04-01 22:58 ` Jan Kiszka 2010-04-01 23:08 ` Gilles Chanteperdrix 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 22:58 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 2083 bytes --] Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible >>>>> "feature" should be dropped at some point, and never ever considered as >>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an >>>>> extra-context switch even in what I think should be _rare_ cases, but >>>>> this has to be done in a way that does not introduce the same kind of >>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode() >>>>> did in the past. >>>>> >>>>> Really, I'm convinced that an awful lot of people are currently running >>>>> under-performing at best, or even broken applications today, because of >>>>> that, thing. >>>> We are not discussing T_PRIMARY here. We are discussing something like >>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that >>>> actually want to provide Ianus-like services. >>>> >>> Yes, we do discuss of T_PRIMARY in between the lines. >>> >> You can take it away, and the rtdm_is_rt_capable-approach would still >> work, but that without affecting existing designs. > > Ok. I almost regret I launched this troll. We have discussed some time > with Philippe, and I agree with him that drivers which this change > really broke were already broken. The only side-effect is the double > switch issue, which, per-se is not that much a trouble in real-world > applications. So what I propose is a special RTDM driver flag that would > somehow fix the issue for the switchtest driver, and would only be used > by that driver and not exported in the rtdm headers, and of course not > documented. > No, I'm queuing rtdm_rt_capable() + a revert of the __xn_exec_conforming commit now. That's way less surprising for existing drivers and still does not require user land to fiddle with the mode. All can be handled at driver level (ie. in Analogy, obviously the only driver that needs it so far). Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 22:58 ` Jan Kiszka @ 2010-04-01 23:08 ` Gilles Chanteperdrix 2010-04-02 0:04 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-01 23:08 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Philippe Gerum wrote: >>>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote: >>>>> Philippe Gerum wrote: >>>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible >>>>>> "feature" should be dropped at some point, and never ever considered as >>>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an >>>>>> extra-context switch even in what I think should be _rare_ cases, but >>>>>> this has to be done in a way that does not introduce the same kind of >>>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode() >>>>>> did in the past. >>>>>> >>>>>> Really, I'm convinced that an awful lot of people are currently running >>>>>> under-performing at best, or even broken applications today, because of >>>>>> that, thing. >>>>> We are not discussing T_PRIMARY here. We are discussing something like >>>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that >>>>> actually want to provide Ianus-like services. >>>>> >>>> Yes, we do discuss of T_PRIMARY in between the lines. >>>> >>> You can take it away, and the rtdm_is_rt_capable-approach would still >>> work, but that without affecting existing designs. >> Ok. I almost regret I launched this troll. We have discussed some time >> with Philippe, and I agree with him that drivers which this change >> really broke were already broken. The only side-effect is the double >> switch issue, which, per-se is not that much a trouble in real-world >> applications. So what I propose is a special RTDM driver flag that would >> somehow fix the issue for the switchtest driver, and would only be used >> by that driver and not exported in the rtdm headers, and of course not >> documented. >> > > No, I'm queuing rtdm_rt_capable() + a revert of the __xn_exec_conforming > commit now. That's way less surprising for existing drivers and still > does not require user land to fiddle with the mode. All can be handled > at driver level (ie. in Analogy, obviously the only driver that needs it > so far). Because of __xn_exec_current, people have broken drivers, and user-space applications using T_PRIMARY as a broken way to workaround these broken drivers, and by maintaining compatibility, we let them keep their broken drivers and applications, by changing to the more natural __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their drivers and applications. What we are left to fix is the corner case of switchtest. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 23:08 ` Gilles Chanteperdrix @ 2010-04-02 0:04 ` Jan Kiszka 2010-04-02 10:39 ` [Xenomai-core] " Gilles Chanteperdrix 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-02 0:04 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 3316 bytes --] Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote: >>>>>> Philippe Gerum wrote: >>>>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible >>>>>>> "feature" should be dropped at some point, and never ever considered as >>>>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an >>>>>>> extra-context switch even in what I think should be _rare_ cases, but >>>>>>> this has to be done in a way that does not introduce the same kind of >>>>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode() >>>>>>> did in the past. >>>>>>> >>>>>>> Really, I'm convinced that an awful lot of people are currently running >>>>>>> under-performing at best, or even broken applications today, because of >>>>>>> that, thing. >>>>>> We are not discussing T_PRIMARY here. We are discussing something like >>>>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that >>>>>> actually want to provide Ianus-like services. >>>>>> >>>>> Yes, we do discuss of T_PRIMARY in between the lines. >>>>> >>>> You can take it away, and the rtdm_is_rt_capable-approach would still >>>> work, but that without affecting existing designs. >>> Ok. I almost regret I launched this troll. We have discussed some time >>> with Philippe, and I agree with him that drivers which this change >>> really broke were already broken. The only side-effect is the double >>> switch issue, which, per-se is not that much a trouble in real-world >>> applications. So what I propose is a special RTDM driver flag that would >>> somehow fix the issue for the switchtest driver, and would only be used >>> by that driver and not exported in the rtdm headers, and of course not >>> documented. >>> >> No, I'm queuing rtdm_rt_capable() + a revert of the __xn_exec_conforming >> commit now. That's way less surprising for existing drivers and still >> does not require user land to fiddle with the mode. All can be handled >> at driver level (ie. in Analogy, obviously the only driver that needs it >> so far). > > Because of __xn_exec_current, people have broken drivers, and user-space > applications using T_PRIMARY as a broken way to workaround these broken > drivers, and by maintaining compatibility, we let them keep their broken > drivers and applications, by changing to the more natural > __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their > drivers and applications. Right goal, wrong approach for the reason I pointed out to Philippe: We cannot map all kinds of driver requirements on a single __xn_exec_current in the RTDM middle layer. RTDM has insufficient knowledge about what the drivers will, how many RT and how may non-RT calls they will provide and what load pattern user space will apply on this. RTDM can only mediate based on the available information. The T_PRIMARY issue has to be solved be removing that feature, not by changing RTDM. > > What we are left to fix is the corner case of switchtest. > ...and the performance degeneration of Analogy when used with a plain Linux tasks - part of the scenario that started this whole discussion. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-02 0:04 ` Jan Kiszka @ 2010-04-02 10:39 ` Gilles Chanteperdrix 2010-04-02 11:11 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-02 10:39 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai-core Redirecting to xenomai core. Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Because of __xn_exec_current, people have broken drivers, and user-space >> applications using T_PRIMARY as a broken way to workaround these broken >> drivers, and by maintaining compatibility, we let them keep their broken >> drivers and applications, by changing to the more natural >> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their >> drivers and applications. > > Right goal, wrong approach for the reason I pointed out to Philippe: > > We cannot map all kinds of driver requirements on a single > __xn_exec_current in the RTDM middle layer. What requirement can we not handle? It looks to me like with __xn_exec_conforming, we can handle any requirement. The only problem being the "double context switch" issue. But as Philippe said, a sane application is calling such ioctls from non critical code, so this is in fact a non-issue. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-02 10:39 ` [Xenomai-core] " Gilles Chanteperdrix @ 2010-04-02 11:11 ` Jan Kiszka 2010-04-02 11:14 ` Gilles Chanteperdrix 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-02 11:11 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, xenomai-core [-- Attachment #1: Type: text/plain, Size: 1452 bytes --] Gilles Chanteperdrix wrote: > Redirecting to xenomai core. > > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Because of __xn_exec_current, people have broken drivers, and user-space >>> applications using T_PRIMARY as a broken way to workaround these broken >>> drivers, and by maintaining compatibility, we let them keep their broken >>> drivers and applications, by changing to the more natural >>> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their >>> drivers and applications. >> Right goal, wrong approach for the reason I pointed out to Philippe: >> >> We cannot map all kinds of driver requirements on a single >> __xn_exec_current in the RTDM middle layer. > > What requirement can we not handle? It looks to me like with > __xn_exec_conforming, we can handle any requirement. > > The only problem being the "double context switch" issue. But as > Philippe said, a sane application is calling such ioctls from non > critical code, so this is in fact a non-issue. And this is one of the restrictions I don't want to keep for upcoming versions. Think of a POSIX app that creates threads, even non-RT ones. Those are automatically shadowed. If those threads perform lots of non-RT service requests on RTDM drivers, they will suffer. The decision about conforming switches is really only driver business. RTDM can only support the driver by providing all required information. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-02 11:11 ` Jan Kiszka @ 2010-04-02 11:14 ` Gilles Chanteperdrix 2010-04-02 11:28 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-02 11:14 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai-core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Redirecting to xenomai core. >> >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Because of __xn_exec_current, people have broken drivers, and user-space >>>> applications using T_PRIMARY as a broken way to workaround these broken >>>> drivers, and by maintaining compatibility, we let them keep their broken >>>> drivers and applications, by changing to the more natural >>>> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their >>>> drivers and applications. >>> Right goal, wrong approach for the reason I pointed out to Philippe: >>> >>> We cannot map all kinds of driver requirements on a single >>> __xn_exec_current in the RTDM middle layer. >> What requirement can we not handle? It looks to me like with >> __xn_exec_conforming, we can handle any requirement. >> >> The only problem being the "double context switch" issue. But as >> Philippe said, a sane application is calling such ioctls from non >> critical code, so this is in fact a non-issue. > > And this is one of the restrictions I don't want to keep for upcoming > versions. Think of a POSIX app that creates threads, even non-RT ones. > Those are automatically shadowed. If those threads perform lots of > non-RT service requests on RTDM drivers, they will suffer. If those threads perform lots of non-RT service requests on RTDM drivers at a non critical time, then no problem. If those threads perform lots of non-RT service requests on RTDM drivers at a critical time and exoect their execution time to be bounded, then you are wrong, because you can not expect any non real-time service to have a bounded execution time anyway. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-02 11:14 ` Gilles Chanteperdrix @ 2010-04-02 11:28 ` Jan Kiszka 2010-04-13 20:41 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-02 11:28 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, xenomai-core [-- Attachment #1: Type: text/plain, Size: 1725 bytes --] Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Redirecting to xenomai core. >>> >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Because of __xn_exec_current, people have broken drivers, and user-space >>>>> applications using T_PRIMARY as a broken way to workaround these broken >>>>> drivers, and by maintaining compatibility, we let them keep their broken >>>>> drivers and applications, by changing to the more natural >>>>> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their >>>>> drivers and applications. >>>> Right goal, wrong approach for the reason I pointed out to Philippe: >>>> >>>> We cannot map all kinds of driver requirements on a single >>>> __xn_exec_current in the RTDM middle layer. >>> What requirement can we not handle? It looks to me like with >>> __xn_exec_conforming, we can handle any requirement. >>> >>> The only problem being the "double context switch" issue. But as >>> Philippe said, a sane application is calling such ioctls from non >>> critical code, so this is in fact a non-issue. >> And this is one of the restrictions I don't want to keep for upcoming >> versions. Think of a POSIX app that creates threads, even non-RT ones. >> Those are automatically shadowed. If those threads perform lots of >> non-RT service requests on RTDM drivers, they will suffer. > > If those threads perform lots of non-RT service requests on RTDM drivers > at a non critical time, then no problem. That's is a needless regression as we now do decisions in the wrong layer without sufficient knowledge about the case. RTDM is just a support layer for the driver, the logic sits in the latter. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-02 11:28 ` Jan Kiszka @ 2010-04-13 20:41 ` Philippe Gerum 2010-04-13 23:05 ` Jan Kiszka 2010-04-14 8:24 ` Gilles Chanteperdrix 0 siblings, 2 replies; 46+ messages in thread From: Philippe Gerum @ 2010-04-13 20:41 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai-core On Fri, 2010-04-02 at 13:28 +0200, Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Jan Kiszka wrote: > >> Gilles Chanteperdrix wrote: > >>> Redirecting to xenomai core. > >>> > >>> Jan Kiszka wrote: > >>>> Gilles Chanteperdrix wrote: > >>>>> Because of __xn_exec_current, people have broken drivers, and user-space > >>>>> applications using T_PRIMARY as a broken way to workaround these broken > >>>>> drivers, and by maintaining compatibility, we let them keep their broken > >>>>> drivers and applications, by changing to the more natural > >>>>> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their > >>>>> drivers and applications. > >>>> Right goal, wrong approach for the reason I pointed out to Philippe: > >>>> > >>>> We cannot map all kinds of driver requirements on a single > >>>> __xn_exec_current in the RTDM middle layer. > >>> What requirement can we not handle? It looks to me like with > >>> __xn_exec_conforming, we can handle any requirement. > >>> > >>> The only problem being the "double context switch" issue. But as > >>> Philippe said, a sane application is calling such ioctls from non > >>> critical code, so this is in fact a non-issue. > >> And this is one of the restrictions I don't want to keep for upcoming > >> versions. Think of a POSIX app that creates threads, even non-RT ones. > >> Those are automatically shadowed. If those threads perform lots of > >> non-RT service requests on RTDM drivers, they will suffer. > > > > If those threads perform lots of non-RT service requests on RTDM drivers > > at a non critical time, then no problem. > > That's is a needless regression as we now do decisions in the wrong > layer without sufficient knowledge about the case. RTDM is just a > support layer for the driver, the logic sits in the latter. You can't regress that much from a wrong situation. It is incorrect already, and this is definitely much more important than a corner case. As we all agreed, this is an issue that makes a number of people think they should or even _have to_ control the current domain their threads are running in. This leads to a fundamental misunderstanding about: 1) how to write efficient apps, 2) how to write sane drivers. This said, I agree that making RTDM syscalls conforming may cause some pre-2.5.2 drivers to break, and unless there is absolutely no other route to get things fixed, we should avoid this. So here is another option I'd like we consider. Actually, it's not a single fix, but rather several steps to fix the situation with respect to (eager) mode management in RTDM drivers and elsewhere. A few assumptions that drive the logic below: - a shadow nrt thread running in secondary mode won't get a significant performance advantage with conforming calls, compared to lazy-switching calls (i.e. __xn_exec_current). The only advantage would come from not running the RTDM syscall prologue twice when calling a rt service, which is admittedly no big deal, in the absence of significant pressure on the RTDM context lock. Since we do want to make nrt shadows automatically switch back to secondary mode at some point, it turns out that the preferred mode of operation for them would not be significantly favored by conforming calls, even when applied to rt services. - applications using rt_task_set_mode(...T_PRIMARY...) or the POSIX skin equivalent via pthead_set_mode_np() are very likely to be wrong. At best, they are adding a useless overhead, at worst, they are assuming too much from the call. E.g. stepping into such code over GDB will defeat the purpose of any switch to primary mode, receiving linux signals as well (and the nucleus may send some of them), and I take for granted that nobody wants utter crap like sigblock +set_mode(T_PRIMARY)+syscall+sigunblock to never ever show up as a common coding pattern in application space. - as an illustration of the previous issue, attempting to control the behavior of a RTDM driver by eagerly switching to the so-called "right" mode before invoking some driver entry points, instead of having the driver implement the proper logic to handle the adaptive switch if both modes are supported, is definitely wrong. - it turns out that we should find a way to leave the mode switch handling where it belongs to, which is in kernel space (nucleus, skins, and drivers), and definitely not in userland. - there is no mode issue wrt shadow rt and plain linux tasks. The preferred exec mode for the latter shall be primary, and the latter only supports secondary mode anyway. So we are only discussing about shadow nrt threads, i.e. Xenomai-enabled SCHED_OTHER threads in userland. The steps now: - we implement the automatic switchback of shadow nrt threads to secondary mode, upon return from Xenomai (primary) syscalls. I am working on this. The most significant impact is on userland, due to the fastsynch support, actually. Kernel-wise, it's rather straightforward. The only exception to this would be when the caller owns an exclusive resource (like a mutex), in which case the mode downgrade should be postponed until the syscall releasing the last resource held returns. - because of the previous fix, there would be no valid use case of forced switches to secondary mode anymore, via rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So we may remove that particular call form, that is most often misused. - it turns out that __xn_exec_conforming is a misnomer, because it rightfully causes a Xenomai nrt thread to switch to primary mode, albeit that thread is inherently a secondary mode beast most of the time (at least it should). We want to describe a syscall that switches the caller to the highest domain it can reach instead, so we should rename this mode bit as __xn_exec_strict for instance, without changing its semantics. - we provide T_CONFORMING instead of T_PRIMARY for rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit number) and the effect intact for existing callers, who are using this to force a Xenomai-enabled rt thread back to primary mode, which could make sense in some rare cases. However the semantics changes: invoking this service from a Xenomai nrt thread would lead to a nop, because the preferred mode of operation is secondary, so any switch to primary shall be nucleus-controlled, and reverted upon syscall return asap. Changing the macro name should also have the useful side effect of forcing a serious code inspection for apps being rebuilt over 2.5.3, so that the reason to switch mode eagerly could be reconsidered, and the app fixed properly. To sum up, 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget -EINVAL, just because you can't ask for a thread to stop being conformant to its basic nature. - then, as you pointed out, we should move the RTDM calls back to __xn_exec_current, and provide rtdm_is_rt_capable() to allow drivers to control the exec mode efficiently via the adaptive syscall scheme. This way, there is no more need to play the T_PRIMARY game in order to implement a syscall differently, depending on whether the caller is a Xenomai shadow, or a plain linux task. The nucleus, the skins and the driver always know better. -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-13 20:41 ` Philippe Gerum @ 2010-04-13 23:05 ` Jan Kiszka 2010-04-14 7:22 ` Philippe Gerum 2010-04-14 8:24 ` Gilles Chanteperdrix 1 sibling, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-13 23:05 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai-core [-- Attachment #1: Type: text/plain, Size: 3882 bytes --] Philippe Gerum wrote: > The steps now: > > - we implement the automatic switchback of shadow nrt threads to > secondary mode, upon return from Xenomai (primary) syscalls. I am > working on this. The most significant impact is on userland, due to the > fastsynch support, actually. Kernel-wise, it's rather straightforward. > The only exception to this would be when the caller owns an exclusive > resource (like a mutex), in which case the mode downgrade should be > postponed until the syscall releasing the last resource held returns. Kernel is clear, but user space sounds indeed interesting. I guess we need an out-of-band channel to tell the kernel about pending user-space-only lock ownerships when calling some unrelated syscall. How does your current approach look like? > > - because of the previous fix, there would be no valid use case of > forced switches to secondary mode anymore, via > rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So > we may remove that particular call form, that is most often misused. > > - it turns out that __xn_exec_conforming is a misnomer, because it > rightfully causes a Xenomai nrt thread to switch to primary mode, albeit > that thread is inherently a secondary mode beast most of the time (at > least it should). We want to describe a syscall that switches the caller > to the highest domain it can reach instead, so we should rename this > mode bit as __xn_exec_strict for instance, without changing its > semantics. > > - we provide T_CONFORMING instead of T_PRIMARY for > rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit > number) and the effect intact for existing callers, who are using this > to force a Xenomai-enabled rt thread back to primary mode, which could > make sense in some rare cases. However the semantics changes: invoking > this service from a Xenomai nrt thread would lead to a nop, because the > preferred mode of operation is secondary, so any switch to primary shall > be nucleus-controlled, and reverted upon syscall return asap. Changing > the macro name should also have the useful side effect of forcing a > serious code inspection for apps being rebuilt over 2.5.3, so that the > reason to switch mode eagerly could be reconsidered, and the app fixed > properly. > > To sum up, > > 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: > rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing > primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. > > 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget > -EINVAL, just because you can't ask for a thread to stop being > conformant to its basic nature. These two still look too complex and inconsistent to grasp. Let's just keep the kernel ABI, ie. let the kernel still interpret the bit (maybe now according to your conforming scheme), but drop T_PRIMARY from the user-visible defines. For the use case of an enforced primary mode switch-back, add a new service - if it is really required. rt_task_set_mode is about static property switching, so adding T_PRIMARY here was already a bad idea from that perspective. > > - then, as you pointed out, we should move the RTDM calls back to > __xn_exec_current, and provide rtdm_is_rt_capable() to allow drivers to > control the exec mode efficiently via the adaptive syscall scheme. This > way, there is no more need to play the T_PRIMARY game in order to > implement a syscall differently, depending on whether the caller is a > Xenomai shadow, or a plain linux task. The nucleus, the skins and the > driver always know better. Will come with my RTDM queue soon. It's delayed as it became too long, and something always needs more work or waits for more testing. Maybe I should start flushing the stable bits. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-13 23:05 ` Jan Kiszka @ 2010-04-14 7:22 ` Philippe Gerum 2010-04-14 7:37 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-14 7:22 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai-core On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > The steps now: > > > > - we implement the automatic switchback of shadow nrt threads to > > secondary mode, upon return from Xenomai (primary) syscalls. I am > > working on this. The most significant impact is on userland, due to the > > fastsynch support, actually. Kernel-wise, it's rather straightforward. > > The only exception to this would be when the caller owns an exclusive > > resource (like a mutex), in which case the mode downgrade should be > > postponed until the syscall releasing the last resource held returns. > > Kernel is clear, but user space sounds indeed interesting. I guess we > need an out-of-band channel to tell the kernel about pending > user-space-only lock ownerships when calling some unrelated syscall. How > does your current approach look like? I want to keep things simple: shadow nrt will go through the syscalls for acquisition/release of owned resources, instead of fastsynchs. > > > > > - because of the previous fix, there would be no valid use case of > > forced switches to secondary mode anymore, via > > rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So > > we may remove that particular call form, that is most often misused. > > > > - it turns out that __xn_exec_conforming is a misnomer, because it > > rightfully causes a Xenomai nrt thread to switch to primary mode, albeit > > that thread is inherently a secondary mode beast most of the time (at > > least it should). We want to describe a syscall that switches the caller > > to the highest domain it can reach instead, so we should rename this > > mode bit as __xn_exec_strict for instance, without changing its > > semantics. > > > > - we provide T_CONFORMING instead of T_PRIMARY for > > rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit > > number) and the effect intact for existing callers, who are using this > > to force a Xenomai-enabled rt thread back to primary mode, which could > > make sense in some rare cases. However the semantics changes: invoking > > this service from a Xenomai nrt thread would lead to a nop, because the > > preferred mode of operation is secondary, so any switch to primary shall > > be nucleus-controlled, and reverted upon syscall return asap. Changing > > the macro name should also have the useful side effect of forcing a > > serious code inspection for apps being rebuilt over 2.5.3, so that the > > reason to switch mode eagerly could be reconsidered, and the app fixed > > properly. > > > > To sum up, > > > > 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: > > rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing > > primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. > > > > 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget > > -EINVAL, just because you can't ask for a thread to stop being > > conformant to its basic nature. > > These two still look too complex and inconsistent to grasp. > > Let's just keep the kernel ABI, ie. let the kernel still interpret the > bit (maybe now according to your conforming scheme), but drop T_PRIMARY > from the user-visible defines. This is exactly what was described: drop T_PRIMARY as a way to fully control the mode from userland, provide T_CONFORMING as a limited action to force a switch back to primary for shadow rt. > For the use case of an enforced primary > mode switch-back, add a new service - if it is really required. > rt_task_set_mode is about static property switching, so adding T_PRIMARY > here was already a bad idea from that perspective. > There is no such limitation to rt_task_set_mode(), and T_CONFORMING is not meant to be used blindly. So, I will stick with this interface. > > > > - then, as you pointed out, we should move the RTDM calls back to > > __xn_exec_current, and provide rtdm_is_rt_capable() to allow drivers to > > control the exec mode efficiently via the adaptive syscall scheme. This > > way, there is no more need to play the T_PRIMARY game in order to > > implement a syscall differently, depending on whether the caller is a > > Xenomai shadow, or a plain linux task. The nucleus, the skins and the > > driver always know better. > > Will come with my RTDM queue soon. It's delayed as it became too long, > and something always needs more work or waits for more testing. Maybe I > should start flushing the stable bits. > > Jan > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-14 7:22 ` Philippe Gerum @ 2010-04-14 7:37 ` Jan Kiszka 2010-04-14 7:51 ` Jan Kiszka 2010-04-14 9:04 ` Philippe Gerum 0 siblings, 2 replies; 46+ messages in thread From: Jan Kiszka @ 2010-04-14 7:37 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai-core [-- Attachment #1: Type: text/plain, Size: 4435 bytes --] Philippe Gerum wrote: > On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> The steps now: >>> >>> - we implement the automatic switchback of shadow nrt threads to >>> secondary mode, upon return from Xenomai (primary) syscalls. I am >>> working on this. The most significant impact is on userland, due to the >>> fastsynch support, actually. Kernel-wise, it's rather straightforward. >>> The only exception to this would be when the caller owns an exclusive >>> resource (like a mutex), in which case the mode downgrade should be >>> postponed until the syscall releasing the last resource held returns. >> Kernel is clear, but user space sounds indeed interesting. I guess we >> need an out-of-band channel to tell the kernel about pending >> user-space-only lock ownerships when calling some unrelated syscall. How >> does your current approach look like? > > I want to keep things simple: shadow nrt will go through the syscalls > for acquisition/release of owned resources, instead of fastsynchs. Then I'll have to pick this up as that will very likely create unhappy customers. In fact, the majority of our Xenomai threads are nrt (yeah, that happens if you convert existing applications). > >>> - because of the previous fix, there would be no valid use case of >>> forced switches to secondary mode anymore, via >>> rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So >>> we may remove that particular call form, that is most often misused. >>> >>> - it turns out that __xn_exec_conforming is a misnomer, because it >>> rightfully causes a Xenomai nrt thread to switch to primary mode, albeit >>> that thread is inherently a secondary mode beast most of the time (at >>> least it should). We want to describe a syscall that switches the caller >>> to the highest domain it can reach instead, so we should rename this >>> mode bit as __xn_exec_strict for instance, without changing its >>> semantics. >>> >>> - we provide T_CONFORMING instead of T_PRIMARY for >>> rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit >>> number) and the effect intact for existing callers, who are using this >>> to force a Xenomai-enabled rt thread back to primary mode, which could >>> make sense in some rare cases. However the semantics changes: invoking >>> this service from a Xenomai nrt thread would lead to a nop, because the >>> preferred mode of operation is secondary, so any switch to primary shall >>> be nucleus-controlled, and reverted upon syscall return asap. Changing >>> the macro name should also have the useful side effect of forcing a >>> serious code inspection for apps being rebuilt over 2.5.3, so that the >>> reason to switch mode eagerly could be reconsidered, and the app fixed >>> properly. >>> >>> To sum up, >>> >>> 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: >>> rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing >>> primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. >>> >>> 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget >>> -EINVAL, just because you can't ask for a thread to stop being >>> conformant to its basic nature. >> These two still look too complex and inconsistent to grasp. >> >> Let's just keep the kernel ABI, ie. let the kernel still interpret the >> bit (maybe now according to your conforming scheme), but drop T_PRIMARY >> from the user-visible defines. > > This is exactly what was described: drop T_PRIMARY as a way to fully > control the mode from userland, provide T_CONFORMING as a limited action > to force a switch back to primary for shadow rt. Not exactly: I'm against T_CONFORMING. > >> For the use case of an enforced primary >> mode switch-back, add a new service - if it is really required. >> rt_task_set_mode is about static property switching, so adding T_PRIMARY >> here was already a bad idea from that perspective. >> > > There is no such limitation to rt_task_set_mode(), and T_CONFORMING is > not meant to be used blindly. So, I will stick with this interface. T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the latter, it is a unique chance to finally drop that misplaced interface from rt_task_set_mode. It's asymmetric and does not really fit into the "true" modes that this interface controls. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-14 7:37 ` Jan Kiszka @ 2010-04-14 7:51 ` Jan Kiszka 2010-04-14 9:04 ` Philippe Gerum 1 sibling, 0 replies; 46+ messages in thread From: Jan Kiszka @ 2010-04-14 7:51 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai-core [-- Attachment #1: Type: text/plain, Size: 1758 bytes --] Jan Kiszka wrote: > Philippe Gerum wrote: >> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: >>> Philippe Gerum wrote: >>>> The steps now: >>>> >>>> - we implement the automatic switchback of shadow nrt threads to >>>> secondary mode, upon return from Xenomai (primary) syscalls. I am >>>> working on this. The most significant impact is on userland, due to the >>>> fastsynch support, actually. Kernel-wise, it's rather straightforward. >>>> The only exception to this would be when the caller owns an exclusive >>>> resource (like a mutex), in which case the mode downgrade should be >>>> postponed until the syscall releasing the last resource held returns. >>> Kernel is clear, but user space sounds indeed interesting. I guess we >>> need an out-of-band channel to tell the kernel about pending >>> user-space-only lock ownerships when calling some unrelated syscall. How >>> does your current approach look like? >> I want to keep things simple: shadow nrt will go through the syscalls >> for acquisition/release of owned resources, instead of fastsynchs. > > Then I'll have to pick this up as that will very likely create unhappy > customers. In fact, the majority of our Xenomai threads are nrt (yeah, > that happens if you convert existing applications). Hmm, thinking about it again, there not that much to optimize in the trivial, non-nested locking case (on entry, we already go through the syscall if we aren't migrated yet, just the release syscall will be new). I will check what share of our load is nested and would actually suffer from unconditional syscalls. I just hope there is no issue with dropping the lazy scheme as that would complicate things in a way I would not want to go as well. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-14 7:37 ` Jan Kiszka 2010-04-14 7:51 ` Jan Kiszka @ 2010-04-14 9:04 ` Philippe Gerum 2010-04-14 17:13 ` Gilles Chanteperdrix 2010-04-14 19:35 ` Jan Kiszka 1 sibling, 2 replies; 46+ messages in thread From: Philippe Gerum @ 2010-04-14 9:04 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai-core On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: > >> Philippe Gerum wrote: > >>> The steps now: > >>> > >>> - we implement the automatic switchback of shadow nrt threads to > >>> secondary mode, upon return from Xenomai (primary) syscalls. I am > >>> working on this. The most significant impact is on userland, due to the > >>> fastsynch support, actually. Kernel-wise, it's rather straightforward. > >>> The only exception to this would be when the caller owns an exclusive > >>> resource (like a mutex), in which case the mode downgrade should be > >>> postponed until the syscall releasing the last resource held returns. > >> Kernel is clear, but user space sounds indeed interesting. I guess we > >> need an out-of-band channel to tell the kernel about pending > >> user-space-only lock ownerships when calling some unrelated syscall. How > >> does your current approach look like? > > > > I want to keep things simple: shadow nrt will go through the syscalls > > for acquisition/release of owned resources, instead of fastsynchs. > > Then I'll have to pick this up as that will very likely create unhappy > customers. In fact, the majority of our Xenomai threads are nrt (yeah, > that happens if you convert existing applications). I would understand that people do not want to bother that much with using the right kind of threads between shadow nrt and plain linux within the context of an initial port, but at some point, the code should be made consistent with respect to the real use. If there is a problem with auto-shadowing in the POSIX skin, or sched_setscheduler() or whatever, then it should be addressed, but we just can't pile up code only to satisfy such a corner case, i.e. situations where applications create Xenomai nrt threads without actual need for this, to make them run in secondary mode only, without requiring a single primary-mode service (hence wanting hard to keep __xn_exec_current for RTDM). So, I will merge the bits I have in mind as a first step, because they satisfy the normal usage of Xenomai threads. I will certainly ACK any improvement to this code which keeps the original fastsynch optimization for nrt threads, provided the feature/code overhead ratio seems correct. > > > > >>> - because of the previous fix, there would be no valid use case of > >>> forced switches to secondary mode anymore, via > >>> rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So > >>> we may remove that particular call form, that is most often misused. > >>> > >>> - it turns out that __xn_exec_conforming is a misnomer, because it > >>> rightfully causes a Xenomai nrt thread to switch to primary mode, albeit > >>> that thread is inherently a secondary mode beast most of the time (at > >>> least it should). We want to describe a syscall that switches the caller > >>> to the highest domain it can reach instead, so we should rename this > >>> mode bit as __xn_exec_strict for instance, without changing its > >>> semantics. > >>> > >>> - we provide T_CONFORMING instead of T_PRIMARY for > >>> rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit > >>> number) and the effect intact for existing callers, who are using this > >>> to force a Xenomai-enabled rt thread back to primary mode, which could > >>> make sense in some rare cases. However the semantics changes: invoking > >>> this service from a Xenomai nrt thread would lead to a nop, because the > >>> preferred mode of operation is secondary, so any switch to primary shall > >>> be nucleus-controlled, and reverted upon syscall return asap. Changing > >>> the macro name should also have the useful side effect of forcing a > >>> serious code inspection for apps being rebuilt over 2.5.3, so that the > >>> reason to switch mode eagerly could be reconsidered, and the app fixed > >>> properly. > >>> > >>> To sum up, > >>> > >>> 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: > >>> rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing > >>> primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. > >>> > >>> 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget > >>> -EINVAL, just because you can't ask for a thread to stop being > >>> conformant to its basic nature. > >> These two still look too complex and inconsistent to grasp. > >> > >> Let's just keep the kernel ABI, ie. let the kernel still interpret the > >> bit (maybe now according to your conforming scheme), but drop T_PRIMARY > >> from the user-visible defines. > > > > This is exactly what was described: drop T_PRIMARY as a way to fully > > control the mode from userland, provide T_CONFORMING as a limited action > > to force a switch back to primary for shadow rt. > > Not exactly: I'm against T_CONFORMING. > > > > >> For the use case of an enforced primary > >> mode switch-back, add a new service - if it is really required. > >> rt_task_set_mode is about static property switching, so adding T_PRIMARY > >> here was already a bad idea from that perspective. > >> > > > > There is no such limitation to rt_task_set_mode(), and T_CONFORMING is > > not meant to be used blindly. So, I will stick with this interface. > > T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the > latter, it is a unique chance to finally drop that misplaced interface > from rt_task_set_mode. It's asymmetric and does not really fit into the > "true" modes that this interface controls. > So, basically T_LOCK is a static switch for you? You mean that locking the scheduler is a static property of any thread? Same for T_NOSIG and blocking asynchronous calls? Look, I designed this interface after the pSOS equivalent, and I can assure you that this was indeed meant to be a mean to control dynamic properties. Now, T_CONFORMING may please us or not, I won't argue about this. I do think that having to switch mode eagerly in the context of an application is the sign that something went wrong at design level somehow. But, we are currently in the middle of a stable 2.5.x series, with a requirement to keep the ABI and the (correct) feature set intact between releases, so the way to fix the T_PRIMARY mess has to be two-fold: - Restrict the usage of T_PRIMARY to the only case where it might make sense in a very limited number of situations. This implies switching back to the preferred mode of operation for a Xenomai rt thread, so that syscall-less sections following a secondary mode switch can still be executed at full rt privileges. - Remove all other uses of T_PRIMARY, because they are at best useless and overkill, at worst plain wrong. To this end, T_PRIMARY becomes T_CONFORMING, and the ABI is kept for the acceptable case. This allow people NOT to recompile their app if they were eargerly switching mode for a valid reason, and force others to fix their applications. Under normal circumstances, I would not even have suggested to touch the API in a stable series for feature removal, but the situation wrt RTDM and the wrong usage of mode switching that obviously started to slip into our own code base (e.g. Analogy) was a wake up call. > Jan > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-14 9:04 ` Philippe Gerum @ 2010-04-14 17:13 ` Gilles Chanteperdrix 2010-04-14 19:35 ` Jan Kiszka 1 sibling, 0 replies; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-14 17:13 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, Jan Kiszka, xenomai-core Philippe Gerum wrote: > On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> The steps now: >>>>> >>>>> - we implement the automatic switchback of shadow nrt threads to >>>>> secondary mode, upon return from Xenomai (primary) syscalls. I am >>>>> working on this. The most significant impact is on userland, due to the >>>>> fastsynch support, actually. Kernel-wise, it's rather straightforward. >>>>> The only exception to this would be when the caller owns an exclusive >>>>> resource (like a mutex), in which case the mode downgrade should be >>>>> postponed until the syscall releasing the last resource held returns. >>>> Kernel is clear, but user space sounds indeed interesting. I guess we >>>> need an out-of-band channel to tell the kernel about pending >>>> user-space-only lock ownerships when calling some unrelated syscall. How >>>> does your current approach look like? >>> I want to keep things simple: shadow nrt will go through the syscalls >>> for acquisition/release of owned resources, instead of fastsynchs. >> Then I'll have to pick this up as that will very likely create unhappy >> customers. In fact, the majority of our Xenomai threads are nrt (yeah, >> that happens if you convert existing applications). > > I would understand that people do not want to bother that much with > using the right kind of threads between shadow nrt and plain linux > within the context of an initial port, but at some point, the code > should be made consistent with respect to the real use. > > If there is a problem with auto-shadowing in the POSIX skin, or > sched_setscheduler() or whatever, then it should be addressed, but we > just can't pile up code only to satisfy such a corner case, i.e. > situations where applications create Xenomai nrt threads without actual > need for this, to make them run in secondary mode only, without > requiring a single primary-mode service (hence wanting hard to keep > __xn_exec_current for RTDM). > > So, I will merge the bits I have in mind as a first step, because they > satisfy the normal usage of Xenomai threads. I will certainly ACK any > improvement to this code which keeps the original fastsynch optimization > for nrt threads, provided the feature/code overhead ratio seems correct. I agree. Let us have your solution merged first, to get to a less troublesome situation (my concern is about switchtest, I am a bit selfish, but switchtest just helped me again solving FPU issues). Optimizations can be taken care of later, especially when we are talking about optimization of shadowed non real-time threads, good performances for them is a nice-to-have, not our primary concern. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-14 9:04 ` Philippe Gerum 2010-04-14 17:13 ` Gilles Chanteperdrix @ 2010-04-14 19:35 ` Jan Kiszka 1 sibling, 0 replies; 46+ messages in thread From: Jan Kiszka @ 2010-04-14 19:35 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai-core [-- Attachment #1: Type: text/plain, Size: 3620 bytes --] Philippe Gerum wrote: > On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> The steps now: >>>>> >>>>> - we implement the automatic switchback of shadow nrt threads to >>>>> secondary mode, upon return from Xenomai (primary) syscalls. I am >>>>> working on this. The most significant impact is on userland, due to the >>>>> fastsynch support, actually. Kernel-wise, it's rather straightforward. >>>>> The only exception to this would be when the caller owns an exclusive >>>>> resource (like a mutex), in which case the mode downgrade should be >>>>> postponed until the syscall releasing the last resource held returns. >>>> Kernel is clear, but user space sounds indeed interesting. I guess we >>>> need an out-of-band channel to tell the kernel about pending >>>> user-space-only lock ownerships when calling some unrelated syscall. How >>>> does your current approach look like? >>> I want to keep things simple: shadow nrt will go through the syscalls >>> for acquisition/release of owned resources, instead of fastsynchs. >> Then I'll have to pick this up as that will very likely create unhappy >> customers. In fact, the majority of our Xenomai threads are nrt (yeah, >> that happens if you convert existing applications). > > I would understand that people do not want to bother that much with > using the right kind of threads between shadow nrt and plain linux > within the context of an initial port, but at some point, the code > should be made consistent with respect to the real use. > > If there is a problem with auto-shadowing in the POSIX skin, or > sched_setscheduler() or whatever, then it should be addressed, but we > just can't pile up code only to satisfy such a corner case, i.e. > situations where applications create Xenomai nrt threads without actual > need for this, to make them run in secondary mode only, without > requiring a single primary-mode service (hence wanting hard to keep > __xn_exec_current for RTDM). The scenario is not that simple - unfortunately. > > So, I will merge the bits I have in mind as a first step, because they > satisfy the normal usage of Xenomai threads. I will certainly ACK any > improvement to this code which keeps the original fastsynch optimization > for nrt threads, provided the feature/code overhead ratio seems correct. Fine with me. >>>> For the use case of an enforced primary >>>> mode switch-back, add a new service - if it is really required. >>>> rt_task_set_mode is about static property switching, so adding T_PRIMARY >>>> here was already a bad idea from that perspective. >>>> >>> There is no such limitation to rt_task_set_mode(), and T_CONFORMING is >>> not meant to be used blindly. So, I will stick with this interface. >> T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the >> latter, it is a unique chance to finally drop that misplaced interface >> from rt_task_set_mode. It's asymmetric and does not really fit into the >> "true" modes that this interface controls. >> > > So, basically T_LOCK is a static switch for you? You mean that locking > the scheduler is a static property of any thread? Same for T_NOSIG and > blocking asynchronous calls? Look, I designed this interface after the > pSOS equivalent, and I can assure you that this was indeed meant to be a > mean to control dynamic properties. Those modes are not static but they can be applied symmetrically and do not change due to other influences. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation 2010-04-13 20:41 ` Philippe Gerum 2010-04-13 23:05 ` Jan Kiszka @ 2010-04-14 8:24 ` Gilles Chanteperdrix 1 sibling, 0 replies; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-14 8:24 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, Jan Kiszka, xenomai-core Philippe Gerum wrote: > On Fri, 2010-04-02 at 13:28 +0200, Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Redirecting to xenomai core. >>>>> >>>>> Jan Kiszka wrote: >>>>>> Gilles Chanteperdrix wrote: >>>>>>> Because of __xn_exec_current, people have broken drivers, and user-space >>>>>>> applications using T_PRIMARY as a broken way to workaround these broken >>>>>>> drivers, and by maintaining compatibility, we let them keep their broken >>>>>>> drivers and applications, by changing to the more natural >>>>>>> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their >>>>>>> drivers and applications. >>>>>> Right goal, wrong approach for the reason I pointed out to Philippe: >>>>>> >>>>>> We cannot map all kinds of driver requirements on a single >>>>>> __xn_exec_current in the RTDM middle layer. >>>>> What requirement can we not handle? It looks to me like with >>>>> __xn_exec_conforming, we can handle any requirement. >>>>> >>>>> The only problem being the "double context switch" issue. But as >>>>> Philippe said, a sane application is calling such ioctls from non >>>>> critical code, so this is in fact a non-issue. >>>> And this is one of the restrictions I don't want to keep for upcoming >>>> versions. Think of a POSIX app that creates threads, even non-RT ones. >>>> Those are automatically shadowed. If those threads perform lots of >>>> non-RT service requests on RTDM drivers, they will suffer. >>> If those threads perform lots of non-RT service requests on RTDM drivers >>> at a non critical time, then no problem. >> That's is a needless regression as we now do decisions in the wrong >> layer without sufficient knowledge about the case. RTDM is just a >> support layer for the driver, the logic sits in the latter. > > You can't regress that much from a wrong situation. It is incorrect > already, and this is definitely much more important than a corner case. > As we all agreed, this is an issue that makes a number of people think > they should or even _have to_ control the current domain their threads > are running in. This leads to a fundamental misunderstanding about: 1) > how to write efficient apps, 2) how to write sane drivers. > > This said, I agree that making RTDM syscalls conforming may cause some > pre-2.5.2 drivers to break, and unless there is absolutely no other > route to get things fixed, we should avoid this. So here is another > option I'd like we consider. Actually, it's not a single fix, but rather > several steps to fix the situation with respect to (eager) mode > management in RTDM drivers and elsewhere. > > A few assumptions that drive the logic below: > > - a shadow nrt thread running in secondary mode won't get a significant > performance advantage with conforming calls, compared to lazy-switching > calls (i.e. __xn_exec_current). The only advantage would come from not > running the RTDM syscall prologue twice when calling a rt service, which > is admittedly no big deal, in the absence of significant pressure on the > RTDM context lock. Since we do want to make nrt shadows automatically > switch back to secondary mode at some point, it turns out that the > preferred mode of operation for them would not be significantly favored > by conforming calls, even when applied to rt services. > > - applications using rt_task_set_mode(...T_PRIMARY...) or the POSIX skin > equivalent via pthead_set_mode_np() are very likely to be wrong. At > best, they are adding a useless overhead, at worst, they are assuming > too much from the call. E.g. stepping into such code over GDB will > defeat the purpose of any switch to primary mode, receiving linux > signals as well (and the nucleus may send some of them), and I take for > granted that nobody wants utter crap like sigblock > +set_mode(T_PRIMARY)+syscall+sigunblock to never ever show up as a > common coding pattern in application space. > > - as an illustration of the previous issue, attempting to control the > behavior of a RTDM driver by eagerly switching to the so-called "right" > mode before invoking some driver entry points, instead of having the > driver implement the proper logic to handle the adaptive switch if both > modes are supported, is definitely wrong. > > - it turns out that we should find a way to leave the mode switch > handling where it belongs to, which is in kernel space (nucleus, skins, > and drivers), and definitely not in userland. > > - there is no mode issue wrt shadow rt and plain linux tasks. The > preferred exec mode for the latter shall be primary, and the latter only > supports secondary mode anyway. So we are only discussing about shadow > nrt threads, i.e. Xenomai-enabled SCHED_OTHER threads in userland. > > The steps now: > > - we implement the automatic switchback of shadow nrt threads to > secondary mode, upon return from Xenomai (primary) syscalls. I am > working on this. The most significant impact is on userland, due to the > fastsynch support, actually. Kernel-wise, it's rather straightforward. > The only exception to this would be when the caller owns an exclusive > resource (like a mutex), in which case the mode downgrade should be > postponed until the syscall releasing the last resource held returns. > > - because of the previous fix, there would be no valid use case of > forced switches to secondary mode anymore, via > rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So > we may remove that particular call form, that is most often misused. > > - it turns out that __xn_exec_conforming is a misnomer, because it > rightfully causes a Xenomai nrt thread to switch to primary mode, albeit > that thread is inherently a secondary mode beast most of the time (at > least it should). We want to describe a syscall that switches the caller > to the highest domain it can reach instead, so we should rename this > mode bit as __xn_exec_strict for instance, without changing its > semantics. > > - we provide T_CONFORMING instead of T_PRIMARY for > rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit > number) and the effect intact for existing callers, who are using this > to force a Xenomai-enabled rt thread back to primary mode, which could > make sense in some rare cases. However the semantics changes: invoking > this service from a Xenomai nrt thread would lead to a nop, because the > preferred mode of operation is secondary, so any switch to primary shall > be nucleus-controlled, and reverted upon syscall return asap. Changing > the macro name should also have the useful side effect of forcing a > serious code inspection for apps being rebuilt over 2.5.3, so that the > reason to switch mode eagerly could be reconsidered, and the app fixed > properly. > > To sum up, > > 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: > rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing > primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. > > 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget > -EINVAL, just because you can't ask for a thread to stop being > conformant to its basic nature. > > - then, as you pointed out, we should move the RTDM calls back to > __xn_exec_current, and provide rtdm_is_rt_capable() to allow drivers to > control the exec mode efficiently via the adaptive syscall scheme. This > way, there is no more need to play the T_PRIMARY game in order to > implement a syscall differently, depending on whether the caller is a > Xenomai shadow, or a plain linux task. The nucleus, the skins and the > driver always know better. This sounds consistent to me, some valid use cases of T_PRIMARY are preserved without keeping T_PRIMARY entirely. -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 19:47 ` Gilles Chanteperdrix 2010-04-01 21:13 ` Jan Kiszka @ 2010-04-01 21:24 ` Philippe Gerum 2010-04-01 21:39 ` Jan Kiszka 2010-04-01 21:50 ` Jan Kiszka 2 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-01 21:24 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, Jan Kiszka, xenomai On Thu, 2010-04-01 at 21:47 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote: > >> Philippe Gerum wrote: > >>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote: > >>>> Hi, > >>>> > >>>> Philippe Gerum wrote: > >>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Sorry for answering so late. I took a few days off far from any internet > >>>>>> connection. > >>>>>> > >>>>>> It seems you sent many mails related with Analogy. Many thanks for your > >>>>>> interest. I have not read all of them yet. However, I am beginning by > >>>>>> this one (which seems unanswered). The answer is quick and easy :) > >>>>>> > >>>>>> Daniele Nicolodi wrote: > >>>>>>> Hello. I'm looking into the analogy cmd_write example. > >>>>>>> > >>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function > >>>>>>> call into the data acquisition loop (lines 413 or 464 in the code > >>>>>>> shipped with xenomai 2.5.1). > >>>>>>> > >>>>>>> I do not understand why we have to set the primary mode at every > >>>>>>> iteration, when we set it before for the task (line 380). > >>>>>>> > >>>>>>> Is it because the dump_function() uses system calls that can make the > >>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing? > >>>>>>> > >>>>>> You are right. The dumping routine triggers a switch to secondary mode. > >>>>>> That is why, the program switches back to primary mode after. > >>>>> This is wrong. The Xenomai core will switch your real-time thread to > >>>>> primary mode automatically when running a4l_insn* calls that end up > >>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point > >>>>> for this one. > >>>>> > >>>> I don't understand. I thought that rt_dev_ioctl() triggered an > >>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared > >>>> with the flags "__xn_exec_current | __xn_exec_adaptive". > >>>> > >>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will > >>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares > >>>> both RT and NRT fops entries), I thought there was no automatic > >>>> mode-switching. > >>> The point is that your ioctl_nrt handler should return -ENOSYS when it > >>> detects that the current request should be processed by the converse > >>> domain, to trigger the switch to primary mode. This is why the adaptive > >>> tag is provided in the first place. > >> The problem is that rtdm does not provide any function to know whether > >> the thread is shadowed. We just have rtdm_in_rt_context() which tells us > >> whether the thread is RT or not. If it is NRT, we cannot distinguish a > >> Linux thread from a Xenomai one. > >> > >> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we > >> could force -ENOSYS if the calling thread was a Xenomai NRT thread: > >> > >> diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c > >> index 8677c47..cc0cfe9 100644 > >> --- a/ksrc/skins/rtdm/core.c > >> +++ b/ksrc/skins/rtdm/core.c > >> @@ -423,6 +423,9 @@ do { \ > >> \ > >> if (rtdm_in_rt_context()) \ > >> ret = ops->operation##_rt(context, user_info, args); \ > >> + else if (xnshadow_thread(user_info) != NULL && \ > >> + ops->operation##_rt != (void *)rtdm_no_support) \ > >> + ret = -ENOSYS; \ > >> else \ > >> ret = ops->operation##_nrt(context, user_info, args); \ > >> \ > > > > No, this would be a half-working kludge. But I think you have pinpointed > > a more general issue with RTDM: syscalls should be tagged as both > > adaptive and conforming, instead of bearing the __xn_exec_current bit. > > Actually, we do want the current domain to change when it is not the > > most appropriate, which __xn_exec_current prevents so far. > > > > What we rather want is to have shadows migrating to primary mode when > > running rtdm_ioctl, since this is the preferred mode of operation for > > Xenomai threads, so that ioctl_rt is always invoked first when present, > > giving an opportunity to forward the request to secondary mode by > > returning -ENOSYS. Conforming calls always enforce the preferred runtime > > mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks. > > That logic applies to all RTDM syscalls actually. > > > > __xn_exec_current allows application code to infer that the RTDM driver > > might behave differently depending on the current runtime mode of the > > calling thread, which is very much error-prone, and likely not what was > > envisioned initially. > > Argh.... The switchtest driver is relying on __xn_exec_current to have > context switches occur precisely in the mode we want. The switchtest driver is aimed at testing that some processing do work reliably in all runtime modes and execution domains, for that reason, it _has to_ control the current mode, and why that code has to understand the inner working of the Xenomai core to trigger exactly what it wants to observe. But this is hardly what a normal application wants to deal with. > __xn_exec_adaptive > introduce more context switches around which we can not place separate > checks for fpu context, so, in short, breaks it badly. Fixing this > requires turning the switchtest driver into a skin with its own syscalls. > Forget about switchtest when discussing the exec/adaptive bits, really. The real issue is with the conforming bit actually. This app is one of a kind, and exactly at the opposite of the normal use case we want to follow the principle of least surprise. switchtest is broken now because it used to rely on an anti-feature that used to break application code. The sad truth is that by fixing the case for the normal application usage, we broke switchtest. But this is at least more acceptable. > Note the sequence which occurs when a shadowed thread running in > secondary mode calls an ioctl for which only an nrt implementation occurs: > the thread is hardened to handle the ioctl > ioctl_rt is called which returns -ENOSYS > the thread is relaxed > ioctl_nrt is called > Yes, and that is to be expected and acceptable. In most drivers, how many calls are implemented as secondary mode _only_, to be fired by rt threads, that would trigger such double-switch? E.g. how many syscalls do require to migrate to secondary because they rely on regular Linux kernel services and may also be called by rt threads? 1%? And of course, none of them can guarantee any real-time behaviour, so you won't invoke them in your time-critical code, which means that one context switch more in this case is not a serious issue. So, it remains that in the overwhelming number of cases, people calling a real-time driver want the driver to do, well, real-time things. And if they don't in some instances, well, they just don't care about one context switch more, to allow real-time threads to downgrade to the proper mode, if this is what really bugs you. > It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm > syscall made by a thread with a shadow, and in fact seems to result in > as bad a result. Is it really what we want? The __xn_exec_current bit > resulted in a more lazy behaviour. > switchtest wants to be lazy. Normal applications don't care a dime, they are mainly dealing with real-time code, that requires real-time mode, and as such a conforming call. __xn_exec_current is actually carrying a MASSIVE bug potential: - stick __xn_current to your favourite syscall, and implement two versions of that syscall, depending on the current calling mode for the shadow thread. - let people think that they should control the current mode of that thread using rt_task_set_mode() and this freaking horror monster called T_PRIMARY, before calling the syscall in question, to get either implementation A or B. - run the stuff, and surprise, get a linux signal between rt_task_set_mode and the syscall. Your thread is now NRT. Too bad, you wanted the RT side to run. You are toast. Besides, you could not even debug your application under GDB sanely in that case, because tracing downgrades the caller to secondary, and __xn_exec_current does not force migration. > Also note that, at least when using the posix skin, almost all threads > have shadows, and only the priority makes the difference between a > really critical thread, and non critical threads with the null priority. > So, this will happen all the time. > Mmm. Is your point that most RTDM drivers out there are implementing mostly linux mode calls to be run in time-critical tight loops? -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:24 ` Philippe Gerum @ 2010-04-01 21:39 ` Jan Kiszka 2010-04-01 21:59 ` Philippe Gerum 0 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 21:39 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 988 bytes --] Philippe Gerum wrote: > __xn_exec_current is actually carrying a MASSIVE bug potential: > - stick __xn_current to your favourite syscall, and implement two > versions of that syscall, depending on the current calling mode for the > shadow thread. > - let people think that they should control the current mode of that > thread using rt_task_set_mode() and this freaking horror monster called > T_PRIMARY, before calling the syscall in question, to get either > implementation A or B. > - run the stuff, and surprise, get a linux signal between > rt_task_set_mode and the syscall. Your thread is now NRT. Too bad, you > wanted the RT side to run. You are toast. That's a non-issue if the driver gets informed about the capability of the caller to execute a service also in RT. In that case, if an RT variant of the invoked service exist, the driver can simply issue the well-know ENOSYS, despite the fact that it could handle the call right now in NRT as well. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:39 ` Jan Kiszka @ 2010-04-01 21:59 ` Philippe Gerum 2010-04-01 22:12 ` Jan Kiszka 0 siblings, 1 reply; 46+ messages in thread From: Philippe Gerum @ 2010-04-01 21:59 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai On Thu, 2010-04-01 at 23:39 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > __xn_exec_current is actually carrying a MASSIVE bug potential: > > - stick __xn_current to your favourite syscall, and implement two > > versions of that syscall, depending on the current calling mode for the > > shadow thread. > > - let people think that they should control the current mode of that > > thread using rt_task_set_mode() and this freaking horror monster called > > T_PRIMARY, before calling the syscall in question, to get either > > implementation A or B. > > - run the stuff, and surprise, get a linux signal between > > rt_task_set_mode and the syscall. Your thread is now NRT. Too bad, you > > wanted the RT side to run. You are toast. > > That's a non-issue if the driver gets informed about the capability of > the caller to execute a service also in RT. In that case, if an RT > variant of the invoked service exist, the driver can simply issue the > well-know ENOSYS, despite the fact that it could handle the call right > now in NRT as well. This is not the issue at stake unfortunately. The problem is with drivers implemented in a way that provides two _different_ implementations of syscalls depending on the current mode. In that case, -ENOSYS and adaptive won't buy you anything. __xn_exec_current will cause your syscall to be routed to the wrong handler as previously illustrated. Saying that anyone writing such a driver is close to being a good candidate for the Darwin Awards is likely true, but as a matter of fact, those driver do exist nonetheless. And the reason why they exist, is because we have that eager mode switch control available to userland, that gives a bad signal to people regarding the semantics of the whole thing. So, to put things in the right sequence: I'm not saying that forcing conforming syscalls is the only option, but it's the only option that _guarantees_ that userland won't shoot itself in the foot in the presence of the T_PRIMARY crap. At the very least, any solution that gives more insight to drivers regarding how to manipulate the current mode should be mated to a converse effort to reduce the nuisance of T_PRIMARY. > > Jan > -- Philippe. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:59 ` Philippe Gerum @ 2010-04-01 22:12 ` Jan Kiszka 0 siblings, 0 replies; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 22:12 UTC (permalink / raw) To: Philippe Gerum; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 2507 bytes --] Philippe Gerum wrote: > On Thu, 2010-04-01 at 23:39 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> __xn_exec_current is actually carrying a MASSIVE bug potential: >>> - stick __xn_current to your favourite syscall, and implement two >>> versions of that syscall, depending on the current calling mode for the >>> shadow thread. >>> - let people think that they should control the current mode of that >>> thread using rt_task_set_mode() and this freaking horror monster called >>> T_PRIMARY, before calling the syscall in question, to get either >>> implementation A or B. >>> - run the stuff, and surprise, get a linux signal between >>> rt_task_set_mode and the syscall. Your thread is now NRT. Too bad, you >>> wanted the RT side to run. You are toast. >> That's a non-issue if the driver gets informed about the capability of >> the caller to execute a service also in RT. In that case, if an RT >> variant of the invoked service exist, the driver can simply issue the >> well-know ENOSYS, despite the fact that it could handle the call right >> now in NRT as well. > > This is not the issue at stake unfortunately. The problem is with > drivers implemented in a way that provides two _different_ > implementations of syscalls depending on the current mode. In that case, > -ENOSYS and adaptive won't buy you anything. __xn_exec_current will > cause your syscall to be routed to the wrong handler as previously > illustrated. > > Saying that anyone writing such a driver is close to being a good > candidate for the Darwin Awards is likely true, but as a matter of fact, > those driver do exist nonetheless. And the reason why they exist, is > because we have that eager mode switch control available to userland, > that gives a bad signal to people regarding the semantics of the whole > thing. > > So, to put things in the right sequence: I'm not saying that forcing > conforming syscalls is the only option, but it's the only option that > _guarantees_ that userland won't shoot itself in the foot in the > presence of the T_PRIMARY crap. At the very least, any solution that > gives more insight to drivers regarding how to manipulate the current > mode should be mated to a converse effort to reduce the nuisance of > T_PRIMARY. > Then it's time to signal the deprecation of T_PRIMARY & co. At least from RTDM POV, there is no need for it anymore (once we resolved the Analogy case). And RTDM was the only valid use case I recall. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 19:47 ` Gilles Chanteperdrix 2010-04-01 21:13 ` Jan Kiszka 2010-04-01 21:24 ` Philippe Gerum @ 2010-04-01 21:50 ` Jan Kiszka 2010-04-01 21:54 ` Gilles Chanteperdrix 2 siblings, 1 reply; 46+ messages in thread From: Jan Kiszka @ 2010-04-01 21:50 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Alexis Berlemont, xenomai [-- Attachment #1: Type: text/plain, Size: 1172 bytes --] Gilles Chanteperdrix wrote: > ... > Argh.... The switchtest driver is relying on __xn_exec_current to have > context switches occur precisely in the mode we want. __xn_exec_adaptive > introduce more context switches around which we can not place separate > checks for fpu context, so, in short, breaks it badly. Fixing this > requires turning the switchtest driver into a skin with its own syscalls. Independent of how switchtest (or RTDM) is fixed again: Do you already have a patch like this in your queue? diff --git a/ksrc/drivers/testing/switchtest.c b/ksrc/drivers/testing/switchtest.c index 057094b..09cd0ec 100644 --- a/ksrc/drivers/testing/switchtest.c +++ b/ksrc/drivers/testing/switchtest.c @@ -665,6 +665,9 @@ static int rtswitch_ioctl_rt(struct rtdm_dev_context *context, struct rttst_swtest_dir fromto; switch (request) { + case RTTST_RTIOC_SWTEST_SET_TASKS_COUNT: + case RTTST_RTIOC_SWTEST_SET_CPU: + case RTTST_RTIOC_SWTEST_SET_PAUSE: case RTTST_RTIOC_SWTEST_REGISTER_UTASK: case RTTST_RTIOC_SWTEST_CREATE_KTASK: case RTTST_RTIOC_SWTEST_GET_SWITCHES_COUNT: I.e. add the missing reflections of NRT IOCTLs. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 257 bytes --] ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [Xenomai-help] Analogy cmd_write example explanation 2010-04-01 21:50 ` Jan Kiszka @ 2010-04-01 21:54 ` Gilles Chanteperdrix 0 siblings, 0 replies; 46+ messages in thread From: Gilles Chanteperdrix @ 2010-04-01 21:54 UTC (permalink / raw) To: Jan Kiszka; +Cc: Alexis Berlemont, xenomai Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> ... >> Argh.... The switchtest driver is relying on __xn_exec_current to have >> context switches occur precisely in the mode we want. __xn_exec_adaptive >> introduce more context switches around which we can not place separate >> checks for fpu context, so, in short, breaks it badly. Fixing this >> requires turning the switchtest driver into a skin with its own syscalls. > > Independent of how switchtest (or RTDM) is fixed again: Do you already > have a patch like this in your queue? > > diff --git a/ksrc/drivers/testing/switchtest.c b/ksrc/drivers/testing/switchtest.c > index 057094b..09cd0ec 100644 > --- a/ksrc/drivers/testing/switchtest.c > +++ b/ksrc/drivers/testing/switchtest.c > @@ -665,6 +665,9 @@ static int rtswitch_ioctl_rt(struct rtdm_dev_context *context, > struct rttst_swtest_dir fromto; > > switch (request) { > + case RTTST_RTIOC_SWTEST_SET_TASKS_COUNT: > + case RTTST_RTIOC_SWTEST_SET_CPU: > + case RTTST_RTIOC_SWTEST_SET_PAUSE: > case RTTST_RTIOC_SWTEST_REGISTER_UTASK: > case RTTST_RTIOC_SWTEST_CREATE_KTASK: > case RTTST_RTIOC_SWTEST_GET_SWITCHES_COUNT: > > I.e. add the missing reflections of NRT IOCTLs. Yes, I had this fix in my tree. But switchtest is broken not only for this reason. I am just waiting what will be decided with regard to the two mode switches when calling an nrt ioctl from a shadowed thread running in secondary mode, to implement a complete fix (most probably rewriting it as a skin). -- Gilles. ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2010-04-14 19:35 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-10 15:26 [Xenomai-help] Analogy cmd_write example explanation Daniele Nicolodi 2010-03-12 23:40 ` Alexis Berlemont 2010-03-13 9:28 ` Philippe Gerum 2010-03-13 16:13 ` Alexis Berlemont 2010-03-13 16:33 ` Philippe Gerum 2010-03-13 23:34 ` Alexis Berlemont 2010-03-14 16:34 ` Philippe Gerum 2010-03-15 7:50 ` Jan Kiszka 2010-03-15 23:30 ` Alexis Berlemont 2010-03-16 8:59 ` Jan Kiszka 2010-03-18 20:35 ` Philippe Gerum 2010-03-18 21:14 ` Alexis Berlemont 2010-03-18 21:39 ` Philippe Gerum 2010-04-01 19:47 ` Gilles Chanteperdrix 2010-04-01 21:13 ` Jan Kiszka 2010-04-01 21:22 ` Philippe Gerum 2010-04-01 21:26 ` Jan Kiszka 2010-04-01 21:31 ` Philippe Gerum 2010-04-01 21:36 ` Jan Kiszka 2010-04-01 21:48 ` Philippe Gerum 2010-04-01 21:54 ` Jan Kiszka 2010-04-01 22:00 ` Philippe Gerum 2010-04-01 22:07 ` Jan Kiszka 2010-04-01 22:53 ` Gilles Chanteperdrix 2010-04-01 22:58 ` Jan Kiszka 2010-04-01 23:08 ` Gilles Chanteperdrix 2010-04-02 0:04 ` Jan Kiszka 2010-04-02 10:39 ` [Xenomai-core] " Gilles Chanteperdrix 2010-04-02 11:11 ` Jan Kiszka 2010-04-02 11:14 ` Gilles Chanteperdrix 2010-04-02 11:28 ` Jan Kiszka 2010-04-13 20:41 ` Philippe Gerum 2010-04-13 23:05 ` Jan Kiszka 2010-04-14 7:22 ` Philippe Gerum 2010-04-14 7:37 ` Jan Kiszka 2010-04-14 7:51 ` Jan Kiszka 2010-04-14 9:04 ` Philippe Gerum 2010-04-14 17:13 ` Gilles Chanteperdrix 2010-04-14 19:35 ` Jan Kiszka 2010-04-14 8:24 ` Gilles Chanteperdrix 2010-04-01 21:24 ` Philippe Gerum 2010-04-01 21:39 ` Jan Kiszka 2010-04-01 21:59 ` Philippe Gerum 2010-04-01 22:12 ` Jan Kiszka 2010-04-01 21:50 ` Jan Kiszka 2010-04-01 21:54 ` Gilles Chanteperdrix
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.