From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BB52769.4080702@domain.hid> Date: Fri, 02 Apr 2010 01:08:25 +0200 From: Gilles Chanteperdrix 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> <4BB51631.5030609@domain.hid> <1270159246.2418.432.camel@domain.hid> <4BB51931.3080307@domain.hid> <4BB523E8.705@domain.hid> <4BB5250F.1040409@domain.hid> In-Reply-To: <4BB5250F.1040409@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Jan Kiszka Cc: Alexis Berlemont , xenomai@xenomai.org 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.