Herman Bruyninckx wrote:
> On Wed, 30 Aug 2000, Trevor Woolven wrote:
>
> [... (in)compatibilities between RTL and RTAI...]
> > However, LineoISG (for whom I work - formerly called Zentropix) have
> > developed a Common API compatibility layer (it's actually a header
> > file) which allows users to write one set of code that can then be
> > used to run either RTAI or RTL.
> >
> > The general idea is that users can now take the same application
> > code and use whichever underlying Real-Time Linux they want. They
> > can also migrate between them as functionality and features
> > change/improve etc.
> How well does this common API follows the evolution of both forks? I
> mean, if RTL comes out with version 3.0, how fast will the common API
> follow this new version? Or will it, by definition, be a greatest
> common divisor of the functionality of both forks?
>
The Common API will be updated once we're happy that a release has
stabilized enough for us to do the work without wasting too much of it.
Obviously, we're susceptible to commercial pressure if customers want
the updates early.
>
> > We would like to see a *real* common API but that starts to get far
> > too political, so for the forseeable future we will maintain our
> > compatibility header and try to keep up with the changes.
> Shouldn't this *real* API be the POSIX-compliant one that RTL is
> trying hard to follow as far as reasonably possible? Or am I stating
> things a bit too simply here...
>
Well, if you look at the Common API it's very simple and the beauty of both
RTL and RTAI is that their 'core' APIs are so similar (for very good
reasons) and simple. The idea behind the Common API is to provide a small,
functional core to allow users to get the maximum, hard real-time
performance from their chosen Real-Time Linux without having to learn a
huge and unwieldy API. A small, well-chosen API that provides all the
necessary real time functionality is what we're after. Unfortunately, there
are subtle differences that (we thought) needed to be covered. Life would
be easier for all of us if the core APIs of RTAI and RTL could be merged
(yes, I know we've been here before!). 'Nuff said...
As to POSIX, we'd need to get a consensus from the providers of RTL and
RTAI on which POSIX calls to implement and which to ignore. I think it's
going to be extremely difficult for anyone to be fully POSIX-compliant (in
this area) due to the size and complexity of the standards (plus you have
to pay for them!). I understand that the standards do not mandate
everything in them (but I don't know which bits as I haven't read the
entire set). To my mind you are either compliant or you're not and
filling-up the grey area with a list of areas of non-compliance just
muddies the water further (and taxes my brain :-).
BTW, can anyone *really* explain the point of non-portable extensions in a
(supposedly) portable standard? I'm not saying they're wrong but they don't
make sense (to me).
>
> --
> [EMAIL PROTECTED] (Ph.D.) Fax: +32-(0)16-32 29 87
> Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
> Real Time and Embedded HOWTO:
> <http://www.mech.kuleuven.ac.be/~bruyninc/rthowto/index.html>
--
Zentropix Inc - a Lineo company
Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482
Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information
-- [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/
