On Thu, Jun 22, 2000 at 11:49:52AM +0100, Stuart Hughes wrote:
> Victor Yodaiken wrote:
> >
> > On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote:
> > > Hi,
> > >
> > > So, if I can't call Linux interrupt handler within an RTAI handler, can
> > > I use two independant handlers ; one from RTAI and the other from Linux?
> >
> > It is trivial to call a Linux interrupt handler from RTLinux.
> > But in RTLinux you do:
> > pthread_kill(rtl_get_linux_thread(cpunumber), RTL_LINUX_MIN_SIGNAL+irq)
> >
> > in pre 2.3 you need the simpler seeming, but nonstandard:
> >
> > rtl_global_pend_irq(irq);
> >
>
> Hi Victor,
>
> pthread_kill may be standard, but AFAIK the signal you use here is not.
That is because having Linux run as a thread is unique to RTLinux.
Our aim is not to pretend to be a standard nonrealtime POSIX, but to
make the api conform to POSIX standard as far as possible. POSIX permits
any number of signals and this extension is therefore within the standard
and seems to me to be a sensible extension. If you have a better idea
or even a good complaint, I'd be happy to hear it.
> Is this just not a 'smoke and mirrors' approach to appear like you are
> following the POSIX standard ??
See above: POSIX mandates pthread_kill and a small number of signals. It
explicitly permits other signals.
"Following the POSIX standard" does not, according to POSIX, forbid
extensions.
My philosophy, with the V2 POSIX API is to provide an API that is clear
and familiar. What I'd like is that if a new RTL programmer wants to send
a signal, she thinks, "hmm, we are in a POSIX threads environment so
it must work via pthread_kill or sigqueue, I'll check the man pages".
Even if the manpages show a extended pthread_kill, this is much better
than, "um, which one of 123 wierd RTOS APIs am I using now? is there
a xmit_irq call, a send_sig, a ... ?"
RTLinux provides a novel programming environment and hard realtime is
itself different from standard programming environments. So new programmers
have an adjustment that is inescapable if they are going to make good
use of the system. By setting ourselves in the Pthread environment, we
minimize the adjustment and, I hope, we make the API coherent instead
of a patchwork of "hey, let's add a functions that does ...".
> If I'm wrong, please accept my apologies, if I'm right then shouldn't we
> *all* try to come up with an existing standard way that can be
> implemented for RTLinux/RTAI ??
Good ideas are in short supply. If you have 'em, I'd like to hear them.
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [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/
