And you don't see NT 3.5 emulation from RTLinux either.
> > I don't understand the appeal of making the kernel slow, failure
> > prone, and incomprehensible by adding incompatible execution modes,
> > but life is full of mysteries.
>
> More FUD. Victor, while RT-Linux has it's uses, so does RT support in
> the main kernel. If you keep slamming the "standard" RT support in the
> kernel, you just come across as being desperate for people to use your
> RT-Linux code.
You are attempting to counter a technical argument with an advertising
speech. I really don't care whether you use RTLinux or not. I do care
whether the main Linux kernel is larded up with garbage.
>
> To address your points:
>
> - making the kernel slow: less so than RT-Linux
Numbers?
>
> - failure prone: the SCHED_IDLE patch just exposed an existing bug
>
You want to describe the design paradigm of the entire kernel as
"an existing bug".
> - incomprehensible: personal opinion of yours with which I don't agree
That's because you don't care whether you understand the implications of
a design change and I do.
>
> - incompatible modes: again a matter of opinion.
Excuse me, but that is utter bullshit. Your example of a "really very
super critical important RT task" using the file system is case in point.
The FS is designed to optimize general thoughput, with no attention at
all to worst case. So once your "RT" task enters the FS, there is nothing
you can say about its timing -- except in the average. How long will you
wait for a buffer to be released by another task? How long will you wait for
the current queue of disk tasks to complete before your request reaches the
driver? etc etc.
There is a need for soft RT support in main Linux and having POSIX RT
is a good thing. But one cannot get "RT" by adding special cases to the
scheduler and blaming the resultant failures on the rest of the system.
As for SCHED_IDLE, unless I've totally missed the point, it's an example
of trying to solve a sys admin problem by breaking the kernel.
How about a cron script that uses nice to make sure that no task is ever
as low priority as the RC5 ?
>
> Regards,
>
> Richard....
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/