* Re: [Xenomai-help] Some basic questions
2006-05-11 14:04 [Xenomai-help] Some basic questions Li Yi (Adam)
@ 2006-05-11 15:49 ` Philippe Gerum
0 siblings, 0 replies; 2+ messages in thread
From: Philippe Gerum @ 2006-05-11 15:49 UTC (permalink / raw)
To: Li Yi (Adam); +Cc: Xenomai-help
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.
^ permalink raw reply [flat|nested] 2+ messages in thread