Re: [ANNOUNCE] Linux 2.6 Real Time Kernel

[Karim Yaghmour]

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@xxxxxxxxxxx || 1-866-677-4546

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/