Re: [Xenomai-help] Analogy cmd_write example explanation

[Alexis Berlemont <berlemont.hauw@domain.hid>]

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.