On Wed, Jan 12, 2000 at 02:01:10PM -0500, Aleksandar Bakic wrote:
> David Olofson <[EMAIL PROTECTED]> writes:
> 
> [...]
> > API functions from RT context is unsafe, as RT context can preempt Linux even if
> > Linux has disabled the interrupts, and hence break spinlock protection and
> > similar stuff. (That is, Linux uses a layer that lets RTL get in between Linux
> > and the IRQ hardware.)
> [...]
> 
> Is there any "trick" to prevent breaking Linux kernel protocols? I've
> had that kind of problems (corrupted data structures in kernel,
> calling scheduler from within an interrupt and similar) :(
> 


In general, no.

In some cases, just duplicate the function and rewrite it as necessary.  A
typical kernel function sometimes looks like:

func()
{
        do_some_stuff;
        spin_lock(&lock);
        critical_stuff;
        spin_unlock(&lock);
        do_more_stuff;
        
        return ret;
}

One possibility for making this clean (in an RT code duplicate), is to
have the function immediately return -EBUSY if it can't get the lock.
That way, you at least know that it failed instead of hanging the
machine.  Keep in mind that this only works on SMP kernels, because
spin_lock() is defined to nothing on non-SMP kernels (it's not necessary).
However, you are never guaranteed that your function suceeds, just
that it doesn't hang the computer.  Of course, if it fails, you have
to make sure that Linux runs again before trying the function again.

Another possibility is to develop a kernel function proxy.  Basically,
you communicate to a Linux task (or kernel task), that you want a
particular operation done, such as 'printk("this is a test\n");'.  When
the Linux task gets scheduled, it does what is requested, and returns
an error/return value.  Whether or not you want this value communicated
to your task is up to you.  rt_printk() is an example of a very simple
proxy, for printk().




dave...

--- [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/

Reply via email to