Great news for POSIX

If you didn’t see the Press announcement, we have just completed our conformance testing of VxWorks to POSIX 1003.13 PSE52 with The Open Group  [IEEE Conformance Web]!!

This adds to the long line of "firsts" for VxWorks, including my favourite of being the first RTOS on MARS!.

As I outlined in my blog on POSIX Profiles then PSE52 or Realtime Controller has 626 APIs and is aimed at small embedded system, with no MMU, and with a disk containing a
simplified file system. In addition remember that SCA 2.2.2 (for JTRS) is a subset of this profile.

This is great news for all DSO developers who need a fast, deterministic Real Time Kernel with POSIX support!

Congratulations to the VxWorks Engineering team for this excellent news!


  1. John Jones

    Hi Alex,
    Congratulations indeed to your engineers on being the first to certify PSE52. My understanding is that this is subset of the POSIX support covered by 1003.1-2003. This is a big step in the right direction, but is seems a bit ‘marketing’ to claim this as a first when it is a subset of a prior certification by a competitor.
    As we previously noted, WRS was committed to providing PSE54 conformance ( in July 2004 and it is listed on as being available in Spring 2006.
    While PSE52 conformance is a wonderful achievement for WRS, for which your engineers deserve kudos, it does fall somewhat short of the expectations WRS has set for us all.
    I look forward to trying the new release.

  2. Alex Wilson

    Thanks for your interest in my last blog!
    I would like to make a couple of comments, one on POSIX and one on roadmaps if I may:-
    On POSIX:
    As you are probably aware POSIX.1 provides a huge list of APIs, some of which are optional (such as POSIX_CLOCK_SELECTION or POSIX_TRACE). So in order to be “conformant” with POSIX.1 you do not need to support these “optional” interfaces. You can find out the support of optional interfaces by looking at a product’s conformance statement.
    POSIX.13 PSE52 also provides a list of APIs that are mostly described by POSIX.1; the one exception I know of is posix_devctl() which is part of POSIX.26, required for POSIX.13′s PSE52 profile, but is not (yet) part of POSIX.1; and is not too much work anyway!
    The main thing that the POSIX.13 profiles do is that they reorganize the POSIX.1 APIs in a way that makes more sense for device software. This makes compulsory some sets of API that are otherwise optional in POSIX.1. This result of this is that you could be conformant to POSIX 1003.1, but NOT conformant to any of the profiles in POSIX 1003.13
    This also means that VxWorks could be conformant to some interfaces that are mandated by POSIX.13 that are not supported by INTEGRITY (as they are optional in POSIX.1).
    What does this all mean to you and me?? Good question – it means that you really need to think about what POSIX support you really need in your final system and what APIs you allow your application developers to use. It means an application written to POSIX.13 PSE 52 will not necessarily run on a pure POSIX.1 system; you need to manage and mandate that all systems in your “System of Systems” support and use the same POSIX standard; at least where you need application portability. Of course it would be relatively easy to add the necessary optional components to a POSIX.1 system that then would allow it to also support POSIX.13 PSE52, but you would need to test against both standards to claim conformance.
    On Roadmaps:
    Successful publicly traded companies like Wind River mark roadmaps “subject to change” because we are driven to keep up with the changing requirements of our customers. As their priorities change we may trade-of on further out features in the roadmaps. The delay in providing POSIX.13 PSE54 is such an example. Having said that, I believe Wind River is committed to POSIX and our increasing compliance with POSIX standards with each release of VxWorks and certification to PSE52 are a direct result of that commitment.

Comments are closed.