From mboxrd@z Thu Jan 1 00:00:00 1970 Sender: Alexis Berlemont Message-ID: <4BA297A5.8030507@domain.hid> Date: Thu, 18 Mar 2010 22:14:13 +0100 From: Alexis Berlemont 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> <4B9DE6BF.2000409@domain.hid> <4B9EC305.4060707@domain.hid> <1268944507.27899.386.camel@domain.hid> In-Reply-To: <1268944507.27899.386.camel@domain.hid> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Philippe Gerum Cc: xenomai@xenomai.org, 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 2010-03-16 01:19:23 Committer: Alexis Berlemont 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.