Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum <rpm@xenomai.org>]

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.

Let's summarize the whole point of forcing primary mode through
rt_task_set_mode(): it's bad, it's wrong, it's counter-productive
CPU-wise, it usually reveals a design issue in the calling code in most
cases.

The only application-level use case where switching to primary mode
eagerly this way might make sense, is when the code first switches to
secondary, then runs an awful lot of CPU-intensive code without issuing
any syscall, one might want to keep un-preempted from Linux IRQs. In
such a case, the question which arises immediately is: why the hell does
one ever tolerate switching to secondary mode initially, if strict
timely behavior is wanted later on? 

That crap is a freaking mistake of mine, when I exported such
anti-feature via the native API mindlessly, to provide a work-around for
rare situations some internal Xenomai code might benefit from. I should
have provided an internal syscall instead, to hide this monster deep
into the abyssal zone it should never have left.

In short: DO NOT USE THIS.

> 
> Almost all the Analogy programs (cmd_read, cmd_write, insn_read,
> insn_write, insn_bits) are just demonstration examples. That is why the
> code is so linear, lengthy and repetitive. Furthermore, the code was not
> meant to be efficient. I just wanted to test the RT and NRT entries.
> 
> By the way, I started to improve them. One change (which is still
> missing) is the use of rtdk.
> 
> > Thanks. Cheers,
> 
> Alexis.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.