> You have to understand I am porting an application from VxWorks.
> Vxworks provides all of the standard utilities in their RTOS.
> This includes IP support (an IP task runs at low priority,
> kinda like LINUX runs in RTLINUX except it is C callable from
> the RT application). Wind River has made a large fortune because
> of this aspect of their RTOS (they charge $20-$30kUs for their RTOS).
> They are however, generally considered **the** premier RTOS (have you
> heard of the MARS rover?)
Yes, VxWorks does it that way. If that's the way you want it and need
it, maybe you should continue using VxWorks. You should reread the
assumptions behind RTL in
http://rtlinux.cs.nmt.edu/~rtlinux/whitepaper/short.html
That is, if you notice that you have to start piling up functionality on
the RT side, and you can't offload most of it to Linux, RTL's
assumptions are not met.
We are using various traditional RTOS's, and that piling up of
functionality on the fragile RTOS causes all kinds of problems: lots of
difficult debugging, priority conflicts, timing unpredictability etc
etc. We are not using RT Linux yet, but it certainly looks like it could
make our products more manageable.
> Essentially what VxWorks has done is what I had to do to get string
> manipulation routines: hack source and accomodate (mostly BSD source).
> Strings are an easy example because there are no system level calls (no
> devices to wait for, etc).
I'm not aware of the library support for RTL, but no doubt lots of such
add-ons will be added in the end.
> Things get much more sticky with things like IP support, filesystems,
> etc.
There you go. I think VxWorks' model is not only heavy-weight, but
possibly also risky because such a small company tries to support life,
universe and everything, a task that seems to be too much even for
Microsoft.
> P.S. I am still stumped as to how the rt_fifio_new.c module calls
> memcpy()....a string.c finction!!!
That's a gcc builtin. Try disassembling it and you'll see there is no
such function.
Here's an excerpt from gcc info:
> `-fno-builtin'
> Don't recognize builtin functions that do not begin with two
> leading underscores. Currently, the functions affected include
> `abort', `abs', `alloca', `cos', `exit', `fabs', `ffs', `labs',
> `memcmp', `memcpy', `sin', `sqrt', `strcmp', `strcpy', and
> `strlen'.
>
> GCC normally generates special code to handle certain builtin
> functions more efficiently; for instance, calls to `alloca' may
> become single instructions that adjust the stack directly, and
> calls to `memcpy' may become inline copy loops. The resulting
> code is often both smaller and faster, but since the function
> calls no longer appear as such, you cannot set a breakpoint on
> those calls, nor can you change the behavior of the functions by
> linking with a different library.
>
> The `-ansi' option prevents `alloca' and `ffs' from being builtin
> functions, since these functions do not have an ANSI standard
> meaning.
Marko
--
Marko Rauhamaa [EMAIL PROTECTED] (818) 878-6314
Sr Project Engineer http://www.tekelec.com/ Tekelec Inc
--- [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/
