With due respect there is a difference between the technical argument
about the right way to do real time, and to clean up or improve the
scheduler (which is undoubtedly possible since Ingo did for 2.2.0)
and continually posting a broken patch because you cannot grasp the
concept of where the standards API/user app interface point is in Linux.
There are two very real camps about the real time type stuff in Linux
1 is the "its either real time or its not". Thats things like rtlinux. If you
say 71uS you get 71uS even if netscape is loading. And for the code modules
that are critical to latency you pay in flexibility and API tools.
2 is the "most is good enough" argument. Thats not generally coming from the
'if we miss the building blows up' department of real time computing but from
the 'I dont want my MP3 files to jump' school - where perfection isnt the aim.
I'm quite interested to see what can be done in #2 without getting to the point
it complicates the kernel. But if you are controlling nuclear power stations
stick to rtlinux because its much much safer.
Alan
-
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/