Messages in this thread | | | Date | Sat, 09 Oct 2004 16:11:16 -0400 | From | Karim Yaghmour <> | Subject | Re: [ANNOUNCE] Linux 2.6 Real Time Kernel |
| |
Lee Revell wrote: > Yes. The upper bound on the response time of an RT task is a function > of the longest non-preemptible code path in the kernel. Currently this > is the processing of a single packet by netif_receive_skb.
And this has been demonstrated mathematically/algorithmically to be true 100% of the time, regardless of the load and the driver set? IOW, if I was building an automated industrial saw (based on a VP+IRQ-thread kernel or a combination of the above-mentioned agregate) with a safety mechanism that depended on the kernel's responsivness to outside events to avoid bodily harm, would you be willing to put your hand beneath it?
How about things like a hard-rt deterministic nanosleep() 100% of the time with RTAI/fusion?
Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || karim@opersys.com || 1-866-677-4546
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |