From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: rt_task_shadow() secondary mode References: <2c2f612c-5a56-0bb7-735c-4d3c4fe13aaa@siemens.com> From: Jan Kiszka Message-ID: Date: Thu, 8 Jul 2021 12:20:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Weinberger Cc: Xenomai On 08.07.21 12:04, Richard Weinberger wrote: > On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka wrote: >> >> On 08.07.21 11:51, Richard Weinberger wrote: >>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka wrote: >>>> The general philosophy of Xenomai is that applications should not rely >>>> on the exact switching behavior. So the question would be why your >>>> application needs one or the other behavior? >>> >>> In this particular case the application uses the ioctl() system call >>> to call into a >>> xenomai kernel module. The module implements the rt and nrt variant of >>> ioctl() and >>> the application assumes which version of the ioctl() implementation >>> will get reached. >> >> ...that might be the actual design bug. If a driver implements the a >> service for both calling modes, the service should effectively do the >> same, ie. should be mode-agnostic. Seems, this was violated here. > > Can be, the driver was designed a long time ago. :-) > In the nrt ioctl() the driver uses e.g. ioremap(), this cannot work in primary > mode. Is the desired approach switching to secondary mode when in primary > mode such a code path is to be executed? > Correct. That is easily achieved by returning -ENOSYS from the rt handler when seeing that nrt request in its context. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux