[EMAIL PROTECTED] wrote:
>
> 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.
Not true, I don't see any disagreement. We still continue to sell the
RTL/2.0.36 based CD. Also we provide tools and support contracts for
either RTL/RTAI.
The decision to use RTAI for our 2.2 based CD was made as a result of
not being able to validate a stable version of RTL for 2.2 back in
July. We were constantly being asked for a 2.2 version and so decided
to look around. We found that RTAI was stable and could run our
regression tests. We have recently found beta16 to be stable. However,
it still lacks support for 486 machines, and IPC.
To me the more serious commercial question is one of copyright and
license. It worries me that rtl_fifo.c is now just 'Copyright VYJ' with
no acknowlegement of its origin (fs/pipe.c). In my opinion this file
should really include the original copyright of Linus Torvalds, and add
the VYJ copyright to that. The only conclusion I can draw from VYJ
trying to reserve exclusive copyright is that one day there will be
non-GPL versions of RTL. This is not wrong, but I think people using
RTL should be aware of this.
We see that with RTAI, there is the clear will to keep it open, and to
acknowledge sources, and respect the original copyrights of derived
works within.
As I, and many on the list have said before, we want to see the the two
respected sources of real time for Linux to merge. One party has
agreed.
> 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".
Maybe you can explain why the latest RTL betas are only available from
fsmlabs.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.
You have missed the point. It seems that everyone but you wants to see
the best of RTL/RTAI merged. I find it a pain to have to write
code/tools that work with similar but different API's. Fundamentaly I
don't see any difference in philosophy between the aims of RTL/RTAI.
They both aim to make hard real time programming available under Linux.
>
> 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.
FP is optional in RTAI. There is no substantive difference in
approaches.
> 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.
Any serious RTOS needs support for semaphores/IPC. whether they are
integrated or not is not the issue. They should be available on all
releases, and not slow down tasks that don't use them.
Regards
Stuart Hughes
.com
--- [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/
