OS Abstraction Layer release

Alan Cudmore Alan.P.Cudmore at nasa.gov
Mon Aug 1 17:27:34 UTC 2005


Peter,
We debated using POSIX for a while too. My original project was to  
use the POSIX APIs for everything. I quickly found that only a couple  
of OSs have a complete enough POSIX API do do what we want. For  
example, RTEMS and QNX provide the mq_timedreceive interface, but  
vxWorks, Linux, Mac OS X, etc.. dont.
I suppose we could have provided the missing POSIX APIs for these  
OSs, rather than create something new, but for Operating systems such  
as Nucleus, they don't have any POSIX APIs, which would require a  
complete implementation ( or a 3rd party purchase, that still is not  
complete enough ).

For the file system, we wanted to have an API as close to POSIX as  
possible, but we wanted the ability to abstract the directory tree/ 
mounted file systems. On vxWorks we can have a Flash file system and  
a RAM disk, and on a Desktop system we can map these file systems to  
a directories on the host OS to allow us to test our code without  
changing paths/filenames etc.

Alan

On Aug 1, 2005, at 12:38 PM, Peter Dufault wrote:

>
> On Aug 1, 2005, at 11:53 AM, Alan Cudmore wrote:
>
>
>> RTEMS users:
>> I thought I would pass along the release of one of our projects,  
>> since it is RTEMS related. In short the OS Abstraction Layer is a  
>> library that allows a portable embedded application to run on  
>> multiple different OSs, including RTEMS.
>>
>>
>
> I quickly looked at this.  I'm curious as to why you didn't choose  
> POSIX as the abstraction layer for the "OS API" and "File System  
> API".  I'm always having the argument with my clients (I know, not  
> a good idea) that these sort of layers ARE what POSIX is defined  
> for, and the client's home-grown wrapper to provide portability is  
> a dumb idea.  I try to phrase it more gently. When a vendor  
> implementation is deficient it's a bug, you work around it with -I  
> wrappers and ugly redefines and report it as a bug to the vendor,  
> without uglifying your own POSIX compliant code.
>
> The "Hardware API" is IMO different since I'm not aware of anything  
> comparable to POSIX.
>
> Peter
>
>




More information about the users mailing list