[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [rtl] RT Ethernet
On Fri, 10 Sep 1999, David Schleef wrote:
>
> > In my opinion the network code in standard Linux is already very close
> > to real-time.
>
> It's not even close. What does mark_bh() mean in an RTLinux interrupt?
OK, I ment the code in network drivers. It calls kmalloc with the highest
priority, it should either return immediately available memory, or fail. Of
course no higher level routines can be used it it should be still real time.
I know this is no longer hard real time, but I also have a feeling that
people writing about RT ethernet do not really need it (I may be wrong, but
please show me a real life situation when 1 ms deadline on the net has to be
met at more than 99.9999 % of cases).
> > Recompiling the whole linux/net and linux/drivers/net subdirectories without
> > -D__RT__ flag and testing it would make very interesting experiment :-)
>
> Don't bother. You've just turned your real-time system into a system that
> only pretends to be real-time.
I know. So we have returned back to the original point: no OS services can
be used if the processing has to be done in hard real time. Calling these
functions will work "most of the time" with all hard to predict consequences.
But then what about testing first if the interrupts are software disabled at
the moment, and if not, behaving like in normal interrupt context? Of course
sometimes test will fail, then the action has to be delayed, and then the
RT-BH mechanism (triggering soft interrupts) which I have demonstrated some
weeks ago would be probably best.
--
Tomek
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/