Re: [Xenomai-help] Some basic questions

[Philippe Gerum <rpm@xenomai.org>]

Li Yi (Adam) wrote:
> Hi,
> 
> I have been getting touch with Xenomai for some time, but I still has 
> some basic confusions (and I think these questions may be common for new 
> users starting to write real-time application using Xenomai).
> 
> 1. If my real-time task want to access the HW resource, like DMA, 
> memory, Network,etc, does the task has to access through Linux kernel 
> service of allocating DMA or allocating memory, etc. Xenomai itself does 
> not provide HW management services, except interrupt and timer. But by 
> using Linux kernel service, the task may suffer from the 
> non-determinstic (non-preemptive) of Linux kernel? Is there any solution 
> for this?
>

Xenomai is there to 1) complement Linux when it fails to be 
deterministic, 2) provide foreign real-time API emulation unknown from 
the Linux environment to port legacy applications. The solution is to 
analyze the requirements of your application, so that you should be able 
to determine which services are really required to be deterministic, and 
in which (calling) contexts.

Some Linux services are inherently non-deterministic, e.g. you can't 
rely on blockable kernel memory allocation requests, or on the TCP 
protocol to get such guarantee. Once you have identified the 
requirements, then you can pick the right tools to fulfill them in the 
Xenomai framework, like the POSIX skin which impersonates most of the 
RT-significant services of the regular POSIX API. If you can afford 
calling the plain Linux services wrt induced latency, Xenomai helps by 
allowing such call seamlessly. Said differently, the fact that an 
application runs over an RTOS does not make it real-time, it's because 
it properly defines its own real-time requirements that such application 
can properly use the RTOS.

> 2. When writing a real-time task dealing with HW (that is, a real-time 
> driver), is the RTDM the prefered interface to use? If I am to make an 
> existing linux driver (for example, an A/D converter driver) real-time, 
> and I don't want to change the code a lot, beside RTDM, what other 
> Xenomai service (API) can I use?

Use RTDM, really.

> 
> 3. Does it make sense that I start a real-time task using the Xenomai 
> native API, while the task calling into Linux network stack (e.g, open a 
> TCP socket)? Since the Linux network stack is not determinstic, the 
> result is the same as I start a normal real-time linux task with 
> SCHED_FIFO or SCHED_RR, that is, the task can be only soft-rt?
> 

First, I would preferably use the POSIX skin and not the native API, to 
keep my application portable from Xenomai to another RT system at low 
cost. Yes, you read me well: Xeno strives to provide doors to get in 
through API-agnosticism, and others to get out through deep integration 
within the Linux environment. This is why the POSIX skin is very 
actively enhanced and maintained.

Aside of this, yes, your analysis is mostly correct, except that TCP is 
a no go for any real-time purpose anyway. To get a deterministic UDP/IP 
network stack, you should have a look at RTNet.

> 4. To create a task to be fully determinstic, I need to make sure the 
> task running in Xonomai domain. When the task need to acess HW, it 
> should not use Linux service. Is that right?
> 

Yes, but since RTDM provides a deterministic impersonation of the basic 
file I/O services, you could just write a RTDM-compliant driver and 
access it normally. Additionally, when MMIO are involved, nothing 
prevents you from dealing with your HW from user-space directly.

> 5. What is the scheduling policy for Xenomai rt task? SCHED_RR or 
> SCHED_FIFO? Sorry I did not found it in the document.
> 

SCHED_FIFO when it is running under the control of the Linux kernel, 
otherwise, it's not applicable since the Xenomai scheduler is 
independent from the latter. The priority level is shared and consistent 
between both execution modes though (primary-Xenomai and secondary-Linux).

> 6. And finally a question specific to Blackfin: What is the purpose of 
> starting a kernel thread for each interrupt handler in Linux kernel?
>

That's a long story, but since you asked for it, here is the main reason:

The culprit is, at your option, either my brain, or the way the Blackfin 
determines the current execution mode of the CPU, either supervisor or 
user, through the IPEND register. As you already know, this register 
tracks the currently processed interrupts, by priority level, and the 
CPU is switched to supervisor mode when at least one interrupt is marked 
as being processed in IPEND. In consequence of what, and due to some 
additional algorithmic hell, one must never perform context switching as 
soon as more than a single interrupt is marked as being processed in 
this register, which conversely means that we must wait for all 
interrupts but the outer one to exit _before_ ever trying to call the 
rescheduling procedure, and this also concerns Xenomai user-space tasks, 
which are initially built over Linux tasks, then put on steroïds afterwards.

If you don't respect this basic "don't schedule in nested interrupt 
context" principle, the kernel will soon end up rescheduling some random 
kernel thread while IPEND is cleared, i.e. out of the supervisor mode, 
which means that the "Illegal use of supervisor resource" fatal 
exception is not far away.

Now, the famous "Houston, we have a problem" episode: then, how are we 
expected to schedule a Xenomai thread asap upon a real-time event, if we 
are required to wait for all the currently nested non-realtime Linux 
ISRs to finish, i.e. the ones that have precisely been preempted by the 
real-time event? The only way I have been able to come up with was to 
move the non-realtime Linux IRQ handlers over threads, and make all 
Linux interrupt top-halves as short as possible, basically posting a 
semaphore in order to wake the associated IRQ thread up. This way, the 
Xenomai rescheduling would only be postponed for a few microseconds in a 
time-bounded way during the execution of the short top-halves, and not 
for a long and unbounded period of time depending on the vanilla kernel 
ISRs.

> Sorry about so many questions and many thanks in advance!
> 
> -Li Yi
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.