"You have to wait until 2.2 is out before trying highly
destabilizing changes and only fix what is obviously
broken in the meantime."
Rik replied:
"Richard's solution of a separate runqueue for RT
processes doesn't look destabilizing to me. The
extra overhead added for normal processes is minimal,
and even if it weren't we shouldn't care because normal
processes don't need fast RT response. The benefit of
Richard's solution - less latency for RT processes -
is a big winner though, because that is the place
where we care about latency and overhead."
"I vote for immediate integration."
Thank you, Rik. I second your vote.
Implementing a separate RT run-queue shouldn't be a big job, for we do not have
to start from scratch. There are plenty of example RT routines available from
RTL [RT Linux] and PicoBSD that we all can study and adapt.
The more important aspect in this discussion should be that the Linux Kernel
Developers must learn to see the big picture.
While this has nothing to do with the "World Domination Joke" some
sources attributed to Linus, we do have to have the foresight of
what Linux may do 5, or 10 years down the line, and beyond !!
In exactly one week, Linux will be 7 years old, (Happy Birthday, Linux !) and
looking closer, we do see a tremendous growth for this 7 year-old baby, and I
see a much brighter future for Linux, for many years to come.
Today, most of us are associating Linux with server operations, and we are all
waiting for some kind of desktop applications to make Linux even more acceptable
to the general public.
But it will be a fallacy if we think Linux can
only shine in the server/desktop environment.
The US Navy is using Windoze NT as their mission critical OS - which I think is
a miserable mistake, but I digress - and if NT can be used for such mission, why
can't Linux?
Perhaps I should re-phrase the question this way:
No matter if NT is able to handle the Navy job or not,
is Linux up to the task?
How sure are we that Linux can handle mission critical jobs?
And the possibilities don't stop at the US Navy.... There are non-military
mission-critical applications as well.
The many space probes under NASA's new "Cheaper and Faster"
program are possible candidates for Linux deployment.
Two other possible civilian uses I can think of offhandedly
include factory automation and vehicle control systems, and
I am certain there are many, many more.
Linux is robust, that we know. But we also must realize that Linux still lacks
many critical features to make it a truly full-rounded OS.
For example, Linux still isn't Fault-tolerance.
We all have the duty to properly prepare Linux for the many possibilities lie
ahead.
Things like the RT run-queue may not be critically
needed right at this moment, but having the RT run-queue
may help Linux, in Richard's case, in its deployment in
the astronomical-related field.
Similarly Fault-tolerance may no longer be a luxury, if we want Linux to be an
OS that can handle tough critical jobs in the real world.
Perhaps Fault-tolerance itself is not a kernel issue per se,
but having the knowledge that something like this is needed
for Linux may encourages people to start develop this
capacity for the Linux community.
I believe we all want Linux to be successful, and in the long run, Linux does
have to acquire extra features to be able to compete with other more established
OS out there.
In conclusion, we must stop boxing ourselves to think that Linux only competes
in the server/desktop environment, and we must try our best to make available
all options for Linux, or all our efforts may eventually go for naught.
Aeeeee! I've move so far off tangent already, better shaddap now or I'll be left
waaaaay in the left field. :)
Regards,
Pete
teamwork@freemail.c3.hu
-
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/