On Wed, Sep 29, 1999 at 02:32:09PM -0500, Guilherme Nelson DeSouza wrote:
> This problem plus some subliminal political dispute that we
> seem to be undergoing in this list can only be damaging to
> this community.
>
Rather than a subliminal political dispute we have two open
disagreements (1) a commercial one and a (2) technical one.
I've started a company to do some commercial development of RTLinux core
code in addition to our work at the university. Zentropix is a company
that previously sold our RTLinux and has apparently
decided to support Paolo's "RTAI" as an alternative commercial
strategy. I wish people would cool the advertising in the list, but
it's natural. So that's the commercial dispute. The technical dispute
is muddier, but I think really comes out of a design philosophy
difference in that RTLinux tries to be as absolutely simple as possible
and RTAI seems to be more oriented towards more features integrated
into the main system. This is a very interesting and positive
development, exactly what we are supposed to get in free software.
Unfortunately we are also getting a little too much "mine is better
than yours" here, but I don't really know if there is a solution other
than the delete key.
Perhaps we need a mail filter that removes all lines containing
".com".
(note how I put that on a line by itself!)
I expect the problem will only get worse as people who have worked in other
lines of development show up with "Chorus/RTLinux" and "SuperMAch/RTLinux"
and whatever, all claiming to be better faster nicer and less fattening
than each other and also to be the "real real time linux".
But that's the price of success, I guess.
Just to put some technical content in this note, RTLinux has a optional
approach to floating point. That is, RTLinux tasks are assumed to not
use FP unles they tell the scheduler that they do want to use FP.
We do this because non FP tasks should not pay any price for saving
and restoring FP registers. RTLinux interrupt handler do not automatically
enable FP, because of the same reason -- in fact, I believe that if you need
FP in an interrupt handler, you are doing something wrong.
Similarly, semaphores are not integrated
into the RTLinux default scheduler because there are many many applications
that do not use semaphores and they should not pay performance costs
for semaphores. I hope to add some non-semaphore based synchronization
primitves in the future and also encourage others to experiment.
And when I began with RTLinux I was convinced that
nobody had any good ideas about scheduling, so the scheduling component
had to be made replaceable. All these are part of our keep it simple
design philosophy and also why I have been very reluctant to take
patches that integrate new features into the core modules instead of
providing compatible "add on " or "Replacement" modules.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
