Sven Heursch wrote:
>
> David Olofson wrote:
>
> > > 2. Are all interrupts disabled while a RT-ISR is running as in Linux?
> >
> > AFAIK, this is the case with the old RTL API, but you can change that
> > behavior if you need to.
> >
>
> I am a little bit confused about the API. I am using RTL V1.1 for Linux 2.0.
> At the moment there is a RTL 1.2 Version for 2.0 Kernel and a RTL V2 for the
> 2.2 Kernel.
> Which one has what API?
RTL 1.2 (for 2.2.x) har the new pthreads API.
> what is the definition for RT safe methods? Do you mean Linux system or
> kernel calls, which should be RT-safe?
Functions that can safely preempt them selves and other related
functions dealing with the same data structures.
If you call a function that uses a standard Linux spin lock from RT
context, you won't have any protection. Standard Linux
spin_lock_irqsave()/spin_unlock_irqrestore() has no effect on RT tasks
and ISRs. On SMP systems, you will get "protection" in that the spinning
will sort of work, but it's not safe. As far as I can tell without
looking at the kernel code again, you'll get a deadlock if an RT task
tries to grab a lock that's held by another task running on the same
CPU. (I'm not sure if the task you are preempting will have a chance to
get away and finish on another CPU. Probably not, as you're blocking
that CPU's scheduler as well, which means other CPUs will think that
"Hey, this task is already running on one of us.", and get on with their
scheduling. You now have one CPU less in your system...)
> > > 5. If 4, can I call a standard linux system call within a RT-ISR? It is
> > > not important for me that the execution of the RT-ISR is fast, but the
> > > reaction on the interrupt must be fast.
> >
> > There are some safe calls, but generally, you can't. RT interrupts DON'T
> > get disabled by spin_lock_irqsave() for example... The standard solution
> > is throwing some data into a struct or some variables, and triggering a
> > standard Linux bottom half handler. (See RT_FIFO code, or rtl_drvsync of
> > the DPI.)
>
> I am using a kill_proc() to send a signal to a standard linux user process.
> It seems to me to work fine.
>From include/linux/sched.h:
#define for_each_task(p) \
for (p = &init_task ; (p = p->next_task) != &init_task ; )
What happens if Linux is in the middle of removing or inserting a task
just before of after the task you're sending the signal to when you come
in preemting it?
Also, from /kernel/exit.c, in function send_sig():
save_flags(flags); cli();
if ((sig == SIGKILL) || (sig == SIGCONT)) {
if (p->state == TASK_STOPPED)
wake_up_process(p);
p->exit_code = 0;
p->signal &= ~( (1<<(SIGSTOP-1)) | (1<<(SIGTSTP-1)) |
(1<<(SIGTTIN-1)) | (1<<(SIGTTOU-1)) );
}
if (sig == SIGSTOP || sig == SIGTSTP || sig == SIGTTIN || sig ==
SIGTTOU)
p->signal &= ~(1<<(SIGCONT-1));
restore_flags(flags);
The cli() has no effect on RTL tasks/ISRs... You'll get away with it
most of the time, but it's not safe.
//David
_ _ _ __ ˇRock solid .-----------------.
/_\ / // \ / /_\ / / / /__/ ˇReal time | Audio hacker |
/ //__//__// / //_ / / _/ ˇ<1 ms latency | Singer/composer |
Professional Linux Audio ˇPlug-ins | GPL advocate |
www.angelfire.com/or/audiality ˇFree/Open Source | Linux advocate |
..-------------------------------------------------' |
| David Olofson ˇ [EMAIL PROTECTED] ˇ [EMAIL PROTECTED] |
´-------------------------------------------------------------------´
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
