And it has bloat, it's famously buggy, it is impossible to maintain, ...
> used. I will be very happy when Linux is as good in all these areas,
> and I'm working hard to achieve this goal with negligible impact on the
> current Linux "sweet-spot" applications such as web serving.
As stated previously: I think this is a proven improbability and I have
not seen any code or designs from you to show otherwise.
> I agree. I'm not wedded to any particular design - I just want a
> low-latency Linux by whatever is the best way of achieving that.
> However, I am hearing Victor say that we shouldn't try to make Linux
> itself low-latency, we should just use his so-called "RTLinux" environment
I suggest that you get your hearing checked. I'm fully in favor of sensible
low latency Linux. I believe however that low latency in Linux will
A. be "soft realtime", close to deadline most of the time.
B. millisecond level on present hardware
C. Best implemented by careful algorithm design instead of
"stuff the kernel with resched points" and hope for the best.
RTLinux main focus is hard realtime: a few microseconds here and there
are critical for us and for the applications we target. For consumer
audio, this is overkill and vanilla Linux should be able to provide
services reasonably well. But ...
> for low-latency tasks. RTLinux is not Linux, it is a separate
> environment with a separate, limited set of APIs. You can't run XMMS,
> or any other existing Linux audio app in RTLinux. I want a low-latency
> Linux, not just another RTOS living parasitically alongside Linux.
Nice marketing line, but it is not working code.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/