From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BB51631.5030609@domain.hid> Date: Thu, 01 Apr 2010 23:54:57 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4B97BA0C.9000702@domain.hid> <4B9AD0DE.4020103@domain.hid> <1268472523.27899.135.camel@domain.hid> <4B9BB9B1.5050003@domain.hid> <1268498034.27899.167.camel@domain.hid> <4B9C2100.6090806@domain.hid> <1268584465.27899.197.camel@domain.hid> <4BB4F857.5020906@domain.hid> <4BB50C8B.2000405@domain.hid> <1270156940.2418.403.camel@domain.hid> <4BB50F7C.1020102@domain.hid> <1270157507.2418.409.camel@domain.hid> <4BB511C7.1050507@domain.hid> <1270158532.2418.420.camel@domain.hid> In-Reply-To: <1270158532.2418.420.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6D817881D1FAB92E3A16202" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] Analogy cmd_write example explanation List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: Alexis Berlemont , xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6D817881D1FAB92E3A16202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 tha= nks for your >>>>>>>>>>>>> interest. I have not read all of them yet. However, I am be= ginning 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_m= ode() function >>>>>>>>>>>>>> call into the data acquisition loop (lines 413 or 464 in t= he 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 c= an make the >>>>>>>>>>>>>> task to switch to secondary mode, or there is a deeper rea= son I'm missing? >>>>>>>>>>>>>> >>>>>>>>>>>>> You are right. The dumping routine triggers a switch to sec= ondary mode. >>>>>>>>>>>>> That is why, the program switches back to primary mode afte= r. >>>>>>>>>>>> This is wrong. The Xenomai core will switch your real-time t= hread to >>>>>>>>>>>> primary mode automatically when running a4l_insn* calls that= end up >>>>>>>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time e= ntry point >>>>>>>>>>>> for this one. >>>>>>>>>>>> >>>>>>>>>>> I don't understand. I thought that rt_dev_ioctl() triggered a= n >>>>>>>>>>> __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 sys= call) will >>>>>>>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy= declares >>>>>>>>>>> both RT and NRT fops entries), I thought there was no automat= ic >>>>>>>>>>> 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 co= nverse >>>>>>>>>> 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 distin= guish a >>>>>>>>> Linux thread from a Xenomai one. >>>>>>>>> >>>>>>>>> I thought with a little patch like this in ksrc/skins/rtdm/core= =2Ec, we=20 >>>>>>>>> could force -ENOSYS if the calling thread was a Xenomai NRT thr= ead: >>>>>>>>> >>>>>>>>> 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 =3D ops->operation##_rt(context, user_info, args); \ >>>>>>>>> + else if (xnshadow_thread(user_info) !=3D NULL && \ >>>>>>>>> + ops->operation##_rt !=3D (void *)rtdm_no_support) \ >>>>>>>>> + ret =3D -ENOSYS; \ >>>>>>>>> else \ >>>>>>>>> ret =3D ops->operation##_nrt(context, user_info, args); \ >>>>>>>>> \ >>>>>>>> No, this would be a half-working kludge. But I think you have pi= npointed >>>>>>>> a more general issue with RTDM: syscalls should be tagged as bot= h >>>>>>>> adaptive and conforming, instead of bearing the __xn_exec_curren= t 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 operatio= n for >>>>>>>> Xenomai threads, so that ioctl_rt is always invoked first when p= resent, >>>>>>>> giving an opportunity to forward the request to secondary mode b= y >>>>>>>> returning -ENOSYS. Conforming calls always enforce the preferred= runtime >>>>>>>> mode, i.e. primary for Xenomai shadows, secondary for plain Linu= x 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 o= f the >>>>>>>> calling thread, which is very much error-prone, and likely not w= hat 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_a= daptive >>>>>>> introduce more context switches around which we can not place sep= arate >>>>>>> checks for fpu context, so, in short, breaks it badly. Fixing thi= s >>>>>>> requires turning the switchtest driver into a skin with its own s= yscalls. >>>>>>> >>>>>>> Note the sequence which occurs when a shadowed thread running in >>>>>>> secondary mode calls an ioctl for which only an nrt implementatio= n 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 resu= lt 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 th= reads >>>>>>> have shadows, and only the priority makes the difference between = a >>>>>>> really critical thread, and non critical threads with the null pr= iority. >>>>>>> So, this will happen all the time. >>>>>> Right. Actually, we only need the conforming property for the (fai= rly >>>>>> 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 a= nd >>>> 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. Ple= ase >>> 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 tho= se >> 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 R= TDM. >> >=20 > 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. >=20 > 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. >=20 > 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 --------------enigF6D817881D1FAB92E3A16202 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAku1FjEACgkQitSsb3rl5xT1TwCgrktj7wVqOZywrmq3GzZb7vNu skoAoOEdXv9IdAUaJsmWGdh2Tc5nG4nM =zeFo -----END PGP SIGNATURE----- --------------enigF6D817881D1FAB92E3A16202--