POSIX surprises. History of the development of the POSIX standard. Who's Who in POSIX Development

POSIX (portable operating system interface) is a standard that describes the interface between operating system and an application program. The purpose of creating this standard is to ensure compatibility of unix-like operating systems, as well as program portability at the source code level. However, the POSIX standard can be used not only by unix systems. The name POSIX was proposed by Richard Stallman. Pronounced "poix" is the interface for portable Unix operating systems.

A little history

First option POSIX standard was IEEE Std 1003. It was released in 1988 and defined the interface between the C programming language and the kernel shell of unix-like systems.

In 1990, a new version of IEEE Std 1003.2 was released. Compared to the first version, minor changes were made in the new document.

In 1992, the two-volume IEEE Std 1003.2 standard was released. The document described a command interpreter and more than a hundred utilities.

The next version, released in 1993, became a small addition to previous versions: information appeared on file synchronization, semaphores, time settings, timer, message queue, asynchronous I/O.

In 1995, another standard dedicated to streams was released, and the 1996 version document was a kind of addition to previous versions.

The 1999 POSIX standard described additional real-time extensions.

In 2001, a standard was released that united all previous versions. It was decided to use it as a basis for the adoption of standards in the future.

The current version of POSIX.1, approved in 2008, is used.

Basic ideas of the POSIX standard

According to documented provisions, for correct interaction with applications, the OS must have the following components:

network tools;
development tools;
control flows;
real-time tools;
package services;
header files;
mathematical interfaces;
legacy interfaces.

Features of operating systems that comply with POSIX standards

differentiation of the rights of users and groups, as well as the superuser root with privileged rights;
the presence of a tree-like file system, which has a single root /;
system and software packages are provided as text files– that is, file configurations can be changed by simple editing;
Unified C programming API;
single standard console utility and commands (POSIX 2).

Operating systems certified according to the POSIX standard include: IBM AIX, UnixWare, Solaris, IRIX, QNX, LynxOS, Mac OS X. OSes such as Minix, various offshoots of BSD, OpenSolaris, VxWorks, OpenWMS are fully compatible with one of the versions of the POSIX standard . Concerning Linux distributions, then most of them comply with the LSB (Linux Standard Base) standard, which in turn is based on POSIX.

Today we will try to find out what the POSIX standard describes. Standards are designed to allow my computer to communicate with yours. Thanks to them, on two similar computers web pages or live video feeds will look the same.

However, standard ones are intended for larger-scale tasks than the simple exchange of any data between users. Some standards define a specific model that opens up capabilities that go far beyond file or network interoperability. The POSIX standard is one of them.

What is POSIX?

POSIX (pronounced "posix") is a portable operating systems interface. But what does it mean? First, you need to define the scope of the concept of “portability”, in this particular case, and define the concept of “interface”. To find out this, it is necessary to start from the fact that both concepts are inextricably linked.

"Portable", in the context of the POSIX standard, refers to source code(not to the binaries that are assembled from these very sources). Now let's find out what an “interface” is. In programming, an "interface" is how your code interacts with other code. The interface expects your code to provide certain information. Your code, in turn, expects to receive certain information from the interface. Good example- fopen() function in C language. It expects information in two parts: the path to the file and the mode in which it will be opened. Using this data, the operating system returns another type of information called a "file descriptor." A file handle can be used to read a file or write to a file. This is the interface. From all this it follows that POSIX-compliant code can be compiled for any POSIX-compliant operating system without major changes, which means it will be portable.

There is a list of interfaces that fall under the POSIX standard, but even though it is very long, it is quite possible that it is incomplete. POSIX is not limited to system calls, it also defines standards for operating system shells (shells, aka command line interfaces), system utilities like "awk" or "echo", system libraries and much more.

The POSIX standard appeared as a draft by Richard Stallman in 1985 and was later formalized as IEEE Std 1003.-1998. As the title suggests, 1998 was the year of official publication. Since then, a large number of additions and extensions to POSIX have been released, which is gradually evolving into an entire family of standards, formally known as IEEE 1003, recognized as international, with the designation SO/IEC 9945, simply called the POSIX family standard.

The operating system does not necessarily need to be POSIX-compliant, much less have a POSIX certificate, but this allows developers to create applications, tools and platforms without rewriting code over and over again, but only adding to and connecting to existing ones. It is also not necessary to write POSIX-compliant code, but this greatly improves the portability of projects between operating systems. This means that the ability to write code that is POSIX compliant is valuable in its own right, and is certainly very useful for one's career. Large projects such as Gnome or KDE adhere to the POSIX standard, which ensures they work on different operating systems. The POSIX subsystem is implemented even in latest issues Windows. Linux is known to support most of the POSIX system calls, as well as a major extension to it called the "Standard Linux base", which is intended to unite Linux distributions in terms of support for source code and binary data.

I hope we have shed some light on the question “what is POSIX”. Possess interesting information on this topic? Please share it in the comments.

POSIX and RT OS: an attempt at systematization

Sergey Zolotarev, Nikolay Gorbunov

The purpose of this article is an attempt to bring some clarity to the history of the development of the POSIX standard in relation to real-time operating systems (RTOS).

As an introduction: why is software interface standardization necessary?

One of the most important properties The POSIX standard is that it defines a "standardized programming interface" that developers of complex hardware and software systems must adhere to. The creators of these systems are forced to deal with requirements such as short time to market (due to fierce competition), minimizing costs and accelerating return on investment. At the same time, the lion's share of the costs caused by the slowdown in the development process is due to the fact that programmers have to “reinvent the wheel”, again and again implementing functionality that has already been available for a long time. But this could have been avoided by:

reusing code from past and parallel projects;
transferring code from other operating systems;
attracting developers from other projects (including using other operating systems).

All this is possible thanks to the use of an OS with a standardized API. Moreover, if in the first case it is enough for an organization to have some kind of internal standard (which is especially typical for proprietary operating systems), then the second two cases require the presence of generally recognized standards - for example, POSIX.

Thus, using a POSIX-compatible OS as a platform for his projects, the developer has the opportunity to transfer finished code at the source level both from his past or parallel projects, and from projects of third parties. This not only significantly reduces software development time, but also improves its quality, since tested code always contains fewer errors.

Who's Who in POSIX Development

And we will start not with the POSIX standard itself, but with streamlining the role of organizations involved in working on it.

The first participant is IEEE(Institute of Electrical and Electronics Engineers), public non-profit association of professionals. IEEE dates back to 1884 (formally since 1963), unites 380,000 individual members from 150 countries, publishes a third of the technical literature relating to the application of computers, control, electrical and information technology, as well as more than 100 journals, popular among professionals; In addition, the association holds over 300 major conferences a year. IEEE has participated in the development of more than 900 current standards (www.ieee.ru/ieee.htm). Today this institute is engaged in the preparation, coordination, approval, and publication of standards, but due to its formal status it does not have the authority to adopt documents such as international or national standards. Therefore, the term “standard” in the understanding of IEEE should rather be understood as a “specification”, which is more consistent with the status of documents accepted by the association. In accordance with IEEE, participates in the programs of a number of international and regional organizations - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standardization) and in national programs, for example in the program of such an organization as ANSI.

IEEE includes PASC (Portable Application Standards Committee), an association committee that develops the POSIX family of standards (www.pasc.org/). PASC was formerly known as the Operating Systems Technical Committee.

The second participant in the work - ANSI(American National Standards Institute, American National Standards Institute) – private non-profit organization, which administers and coordinates standardization activities in the United States. It employs only 75 people, but ANSI members include more than 1,000 companies, organizations, government agencies and institutions (www.ansi.org). ANSI represents the United States in the two major international standards organizations, ISO and IEC.

Third participant - ISO(International Organization for Standardization, International Organization for Standardization). It was created in 1946 by decision of the Committee for the Coordination of Standards and the UN General Assembly and officially began work on February 23, 1947 (www.iso.org). ISO is a network national institutions for standardization from 146 countries (one country - one ISO member) with a central secretariat in Geneva (Switzerland). ISO standards are developed in technical committees, the first result of which is the Draft International Standard (DIS), which, after several approvals, turns into the Final Draft International Standard (FDIS). After this, the issue of approval of this document is put to a vote; if the result is positive, it becomes an international standard.

And finally - IEC(International Electrotechnical Commission, International Electrotechnical Commission - IEC), founded in 1906. IEC prepares and publishes international standards for all electrical, electronic and related technologies (www.iec.ch/). As of November 1, 2004, national committees of 64 countries were active members of this commission. The IEC also issues recommendations, which are published in English and French and have the status of international standards. On their basis, regional and national standards are developed. Technical committees (TCs) are responsible for the preparation of standards in various areas of IEC activities, in the work of which national committees interested in the activities of a particular TC also take part.

IEC is the key organization in the preparation of international standards for information technology. In this area there is a joint technical committee on information technology, JTC 1, formed in 1987 in accordance with an agreement between IEC and ISO. JTC1 has 17 subcommittees overseeing all developments - from software to programming languages, computer graphics and image editing, hardware interconnections and security techniques.

The preparation of new IEC standards includes several stages (preliminary, proposal, preparatory, technical committee, request, approval, publication). If the IEC document is intended to become only technical specification, rather than an international standard, a revised version of the document is sent to the central office for publication. Four months are allotted for the development of the final draft international standard (FDIS). If it is approved by all members of the technical committee, it is sent to the central office for publication without the FDIS approval stage. The FDIS then goes to national committees, which must approve it within two months. The FDIS is considered approved if more than two-thirds of the national committees vote for it, and the number of negative votes does not exceed 25%. If a document is not approved, it is sent to technical committees and subcommittees for review. The standard must be published no later than two months after FDIS approval.

Several other organizations are involved in the development and adoption of POSIX standards.

Open Group is an international software standards organization that brings together almost 200 manufacturers and user communities working in the field of information technology (www.opengroup.org/). The Open Group was created in 1995 by merging its two predecessors: X/Open and the Open Software Foundation (OSF). Open Group specializes in developing software certification methodologies and testing for compliance with specific requirements. In particular, the Open Group is engaged in certification for such areas as COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) and, finally, POSIX family of standards (www.opengroup.org/certification/).

Austin Common Standards Revision Group (CSRG)– a joint technical working group formed in 2002 by ISO, IEC and Open Group to create and maintain the latest versions of the 1003.1 standard, which will be formed on the basis of ISO/IEC 9945-1-1996, ISO/IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 and Single UNIX Specification (www.opengroup.org/press/14nov02.htm).

National Institute of Standards and Technology (NIST) is a federal agency within the Commerce Department’s Technology Administration (www.nist.gov/public_affairs/general2.htm), founded in the USA in 1901. NIST’s mission is to develop and promote standards and technologies to improve product quality. NIST includes an Information Technology Laboratory (ITL), one of the results of which is the Federal Information Processing Standards (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST/ITL proposed the initial set of tests for POSIX certification in 1991 under FIPS PUB 151-1 1990.

What is POSIX?

Formally the term POSIX proposed by Richard Stallman as an abbreviation for P ortable O perating S system interface for un IX(portable operating system interface for Unix). POSIX was developed for UNIX-like operating systems (their first versions date back to the early 1970s) with the goal of ensuring application portability at the source level.

The initial description of the interface was published in 1986, then it was called IEEE-IX (IEEE's version of UNIX). However, the name quickly changed, becoming POSIX, and already in the next publication (back in 1986) this new option. For some time, POSIX was understood as a reference (or synonym) to the group of related documents IEEE 1003.1-1988 and parts of ISO/IEC 9945, and as a complete and approved international standard, ISO/IEC 9945.1:1990 POSIX was adopted in 1990. The POSIX specifications define the standard interaction mechanism application program and OS and currently includes more than 30 standards under the umbrella of IEEE, ISO, IEC and ANSI.

POSIX has come a long way throughout its history, with numerous changes to the designation of the specifications, their specific content, the procedures and logistics for testing them. Over time, several editions of the POSIX standard have been released within various international organizations.

History of the development of the POSIX standard

The first version of the IEEE Std 1003.1 specification was published in 1988. Subsequently, numerous editions of IEEE Std 1003.1 have been adopted as international standards.

POSIX development stages:

1990

The edition, released in 1988, was revised and became the basis for further editions and additions. It has been approved as an international standard by ISO/IEC 9945-1:1990.

1993

Revision 1003.1b-1993 is released.

1996

IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, and 1003.1i-1995 have been amended, but the body of the document remains unchanged. The 1996 edition of IEEE Std 1003.1 was also adopted as an international standard by ISO/IEC 9945-1:1996.

1998

The first standard for "real time" appeared - IEEE Std 1003.13-1998. It is an extension of the POSIX standard for embedded real-time applications.

1999

It was decided to make the first significant changes in the last 10 years to the main text of the standard, including integration with standard 1003.2 (Shell and utilities), since at that time these were separate standards. PASC decided to complete the changes base text upon completion of IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b standards.

2004

The latest revision of the 1003.1 standard was published on April 30 and was released under the auspices of the Austin Common Standards Revision Group. It is amended by the 2001 edition of the standard. Formally, the 2004 edition is known as IEEE Std 1003.1, 2004 Edition, The Open Group Technical Standard Base Specifications, Issue 6 and includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and IEEE Std 1003.1-2001/Cor 2-2004.

The most important POSIX standards for RT OS

For real-time operating systems, seven standard specifications are most important (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), but only three have received widespread support in commercial operating systems:

1003.1a (OS Definition) defines the main OS interfaces, job management, signals, file system and device functions, user groups, pipelines, FIFO buffers;
1003.1b (Realtime Extensions) describes real-time extensions such as real-time signals, priority scheduling, timers, synchronous and asynchronous I/O, semaphores, shared memory, messages. This standard was originally (until 1993) designated POSIX.4.
1003.1c (Threads) defines functions for supporting threads (threads) - thread management, thread attributes, mutexes, dispatching. Originally designated POSIX.4a.

In addition to these standards, the following standards are important for the RT OS, which were implemented as part of the work on the Std 1003.1-2001 project:

IEEE 1003.1d-1999. Additional real-time extensions. Originally designated as POSIX.4b;
IEEE 1003.1j-2000. Improved (advanced) real-time extensions;
IEEE 1003.1q-2000. Trace.

Certification procedure

To comply with the POSIX standard, the operating system must be certified according to the results of the appropriate test suite. Since the introduction of POSIX, the test suite has undergone formal and factual changes.

In 1991, NIST developed the POSIX testing program as part of FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). This test case was based on IEEE 1003.3" Standard for Test Methods for Measuring Conformance to POSIX" Draft 10, May 3, 1989. In 1993, NIST completed the POSIX Testing Program for FIPS 151-1 and began the program for FIPS 151-2 (www.itl.nist.gov /fipspubs/fip151-2.htm). FIPS 151-2 adapted "Information Technology - Portable" Operating System Interface (POSIX) – Part 1: System Application Program Interface (API)," which is an ISO/IEC 9945-1:1990 standard. Test suites for FIPS 151-2 were based on IEEE 2003.1-1992 "Standard for Test Methods for Measuring Conformance to POSIX".

NIST distinguishes between two certification methodologies: self-certification and certification by IEEE Accredited POSIX Testing Laboratories (APTL). In the first case, the company conducts testing independently, but according to a plan approved by NIST. In the second case, testing is performed by an independent laboratory using automated test kits. In total, two APTL laboratories were accredited: Mindcraft (www.mindcraft.com) and Perennial (www.peren.com).

In 1997, NIST/ITL announced its intention to cease FIPS 151-2 certification at the end of the current year (officially December 31, 1997), while the Open Group announced that it intended to take over the certification as of October 1, 1997. same year, certification service in accordance with FIPS 151-2, based on the NIST/ITL program. The same functions were taken over by the IEEE Standards Association (IEEE-SA) on January 1, 1998, also based on FIPS 151-2.

In 2003, IEEE-SA and the Open Group announced the start of a new joint program to certify the latest versions of POSIX, starting with IEEE 1003.1™ 2001. The Open Group now has several test suites that cover IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 ,IEEE Std 1003.1-2003 and IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). A product is considered POSIX certified if it has passed full procedure certification, based on testing results, satisfies all requirements and is included in the official register certified products.

Test suites include:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) – a set of conformance tests for system interfaces IEEE Std 1003.1-1990;
VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) – a set of conformance tests for IEEE Std 1003.13-1998 Profile PSE54 (multi-purpose real time);
VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) – a set of conformance tests for system interfaces IEEE Std 1003.1-2003 (only mandatory parts);
VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) – a set of conformance tests for IEEE Std 1003.1-2003 (shell and utilities – only mandatory parts).

In addition, the Open Group has developed tests for the POSIX Realtime standards and the Embedded POSIX standards profile. The POSIX Realtime test suite (www.opengroup.org/testing/testsuites/realtime.html) includes the following tests:

IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime extension and IEEE POSIX 1003.1,2003 Edition;
IEEE Std POSIX 1003.1c-1995 Threads (pthreads) extension and IEEE POSIX 1003.1,2003 Edition;
IEEE POSIX 1003.1d-1999 Additional Realtime Extension and IEEE POSIX 1003.1,2003 Edition;
IEEE POSIX 1003.1j-2000 Advanced Realtime Extension and IEEE POSIX 1003.1,2003 Edition;
IEEE POSIX 1003.1q-2000 Trace and IEEE POSIX 1003.1,2003 Edition and IEEE POSIX 1003.1,2003 Edition;

The Embedded POSIX standards profile test suite (www.opengroup.org/testing/testsuites/embedded.html) includes the following tests:

IEEE POSIX 1003.1-1990 (5310 tests);
IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime extension (1430 tests);
IEEE Std POSIX 1003.1c-1995 Threads (pthreads) extension (1232 tests);
IEEE POSIX 1003.13-1998 Profile 52.

A little about confusion in terminology

In relation to the POSIX group of standards, not one, but three terms are often used in English. Unfortunately, they are similar in meaning and are often translated the same way, which creates some confusion. These terms are:

compatibility (literally “compatibility”);
compliance (literally “compliance”);
conformance (literally “consistency”).

The first term, as applied to POSIX, is not formally defined. The second means that the organization that produces the software product independently declares that this product (fully or partially) complies with the listed NIST-PCTS standards. The third term implies that software has passed the established system of tests either with the help of an accredited laboratory or within the Open Group and there is documentary evidence of this (the so-called Conformance Statement). Further in the text of the article, the original terms will be given everywhere in order to eliminate ambiguity.

Certified OS RV

If you stick to strict rules, requiring that data on a certified RT OS be published in the official registry and testing be carried out according to the conformance level, then currently there are only two certified RT OSs (data are given in chronological order):

LynxOS v.3(a product of Lynx Real-Time Systems, now called LynuxWorks, Inc., www.lynuxworks.com) is intended for developing software for embedded systems operating in hard mode real-time, OEM and telecommunications equipment manufacturers, in particular manufacturers of military airborne systems. Development can be carried out both on the target system itself (self-hosted) and on an instrumental computer (host), ready-made software is designed to work on the target system. LynxOS v.3 is certified for conformance to the POSIX standard on the Intel and PowerPC platforms. Information about this can be found on the IEEE website http://standards.ieee.org/regauth/posix/posix2.html. LynxOS is certified to POSIX 1003.1-1996 by Mindcraft, an IEEE POSIX Accredited POSIX Testing Laboratory against the NIST FIPS 151-2 Conformance Test Suite. Certification document number: Reference File: IP-2LYX002, Reference File: IP-2LYX001.

INTEGRITY v.5(a product of Green Hills Software, www.ghs.com) is certified for conformance to POSIX 1003.1-2003, System Interfaces for the PowerPC architecture in July 2004 (http://get.posixcertified.ieee.org/select_product. tpl). VSX-PCTS 2003 test suite.

POSIX and the QNX operating system

QNX v.4.20 (developed by QNX Software Systems, www.qnx.com) is certified for compliance with POSIX 1003.1-1988 for Intel platforms by DataFocus Incorporated. Testing was conducted on September 13, 1993, and the document was issued on November 1, 1993. NIST PCTS 151-1 Test Suite, Version 1.1.

QNX Neutrino (version 6.3) complies to following standards POSIX family (www.qnx.com/download/download/8660/portability.pdf):

POSIX.1 (IEEE 1003.1);
POSIX.1a (IEEE 1003.1a);
POSIX.2 (IEEE 1003.2);
POSIX.4 (IEEE 1003.1b);
POSIX.4a (IEEE 1003.1c);
POSIX.1b (IEEE 1003.1d), IEEE 1003.1j;
POSIX.12 (IEEE 1003.1g).

QNX Software Systems, the creator of QNX Neutrino, also plans to conform QNX Neutrino to some of these standards; work is planned for 2005 (www.qnx.com/news/pr_959_1.html).

Literature

IEEE Standards Association Operation Manual. IEEE, October 2004.
Kevin M. Obeland. POSIX in Real-Time, Embedded Systems Programming, 2001.
IEEE/ANSI Standard 1003.1: Information Technology – (POSIX) – Part1: System Application: Program Interface (API).
Gallmeister, B.O. Programming for the Real World, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.
National Institute of Standards and Technology, PCTS:151-2, POSIX Test Suite.
POSIX: Certified by IEEE and The Open Group. Certified Policy. The Open Group, October 21, 2003, Revision 1.1.

Software) is a task of exceptional importance and complexity; in our time, this circumstance hardly needs extensive justification. One of the generally accepted ways to increase software portability is to standardize the application environment: provided software interfaces, utilities, etc. At the level system services a similar environment is described by the POSIX standard (Portable Operating System Interface - mobile operating system interface); The name was proposed by the famous specialist, founder of the Free Software Foundation, Richard Stallman.

We will consider the most modern version of the POSIX standard available, the 2003 edition, which can be called the "triple standard", namely IEEE Std 1003.1, Technical standard Open Group and (see [6]), most importantly for us, the international standard ISO/IEC 9945 (see [1], [2], [3], [4]).

The history of the creation of this version is as follows. In early 1998, representatives of three organizations—the Mobile Application Standards Committee of the Institute of Electrical and Electronics Engineers, the Open Group, and Joint Technical Committee 1 Subcommittee 22 Working Group 15 (JTC1/SC22/WG15) of the International Standards Organization—began consultations on the merger and the development of interface standards for system services supervised by them: IEEE Std 1003.1, IEEE Std 1003.2, Basic specifications from the Open Group, ISO / IEC 9945-1, ISO / IEC 9945-2. In September of the same year, an organizational meeting of the group formed to achieve this goal was held in Austin, Texas, at the office of IBM Corporation (see http://www.opengroup.org/austin).

The foundational document for the revised standard, the first draft of which was submitted in July 1999, was the Open Group's Core Specifications, as it incorporated provisions from the IEEE and ISO/IEC standards. In 2001, upon completion of the preparatory work, the standard contained the following four parts:

basic definitions (terms, concepts and interfaces common to all parts);
description C application programming interface to system services;
description of the interface to system services at the level command language And utilities ;
detailed explanation of the provisions of the standard, rationale for decisions made.

As the standard developed, the interpretation of the term "POSIX" expanded. It originally referred to IEEE Std 1003.1-1988, which described application programming interface Unix class OS. After standardization of the interface at the level of the command language and utilities, it is more correct to understand the word "POSIX" as a standard as a whole, denoting the above parts 2 and 3 through POSIX.1 and POSIX.2 in accordance with the numbering of IEEE and ISO/IEC documents.

Basic ideas of the POSIX standard

Every interface has two sides: the caller and the calledee. The POSIX standard is caller-oriented. Its goal is to make applications mobile at the source language level. This means, in particular, that when moving C programs to another operating platform, recompilation will be required. There is no talk about the mobility of executable programs and/or object files.

The POSIX standard is by no means limited to the Unix environment. There are operating systems (OS) of "independent origin" (for example, real time systems), providing the necessary services and thereby supporting the execution of POSIX-compliant applications. It can be argued that following the POSIX standard makes it easier to port applications to almost any widely used operating platform. The extra effort put into improving mobility during the development phase will certainly pay off.

By defining the interface to system services, POSIX leaves their implementation out of consideration. In particular, they do not differ system calls And library functions. Products are not subject to standardization administration, hardware limitations and features required only superuser, which once again emphasizes the focus of the standard

Ensuring mobility (portability) of software is a task of exceptional importance and complexity; in our time, this circumstance hardly needs extensive justification. One of the generally accepted ways to increase software portability is to standardize the application environment: provided software interfaces, utilities, etc. At the level system services a similar environment is described by the POSIX standard (Portable Operating System Interface - mobile operating system interface); The name was proposed by the famous specialist, founder of the Free Software Foundation, Richard Stallman. We will be looking at the most modern version of the POSIX standard available, the 2003 edition, which can be called the "triple standard", namely IEEE Std 1003.1, the Open Group Technical Standard and (see, most importantly for us, the international standard ISO/IEC 9945 (see , , , ). The history of the creation of this version is as follows: In early 1998, representatives of three organizations - the Mobile Application Standards Committee of the Institute of Electrical and Electronics Engineers, the Open Group and Working Group 15 of Subcommittee 22 of the Joint Technical Committee. 1 (JTC1/SC22/WG15) of the International Organization for Standardization - began consultations on the issue of merging and developing the standards for interfaces to system services they oversee: IEEE Std 1003.1, IEEE Std 1003.2, Basic Specifications from the Open Group, ISO/IEC 9945-1, ISO /IEC 9945-2. In September of the same year, an organizational meeting of the group formed to achieve this goal was held in Austin, Texas, at the office of IBM Corporation (see. http://www.opengroup.org/austin). The foundational document for the revised standard, the first draft of which was submitted in July 1999, was the Open Group's Core Specifications, as it incorporated provisions from the IEEE and ISO/IEC standards. In 2001, upon completion of the preparatory work, the standard contained the following four parts:

basic definitions (terms, concepts and interfaces common to all parts);

description of the C application software interface to system services;

description of the interface to system services at the level command language And utilities;

detailed explanation of the provisions of the standard, rationale for decisions made.

Further, ISO, IEEE and the Open Group, with greater or lesser speed (in 2001-2002), formally approved the new POSIX standard. Meanwhile, relatively minor corrections accumulated and were taken into account in the 2003 edition. As the standard developed, the interpretation of the term "POSIX" expanded. It originally referred to IEEE Std 1003.1-1988, which described application programming interface Unix class OS. After standardization of the interface at the level of the command language and utility programs, it is more correct to understand the word "POSIX" as a standard as a whole, denoting the above parts 2 and 3 through POSIX.1 and POSIX.2 in accordance with the numbering of IEEE and ISO/IEC documents.

Basic ideas of the POSIX standard

The POSIX standard describes many basic, system services necessary for the functioning of application programs. They are accessed through an interface specified for the C language, a command language, and common utility programs. Every interface has two sides: the caller and the calledee. The POSIX standard is caller-oriented. Its goal is to make applications mobile at the source language level. This means, in particular, that when moving C programs to another operating platform, recompilation will be required. There is no talk about the mobility of executable programs and/or object files. The POSIX standard is by no means limited to the Unix environment. There are operating systems (OS) of "independent origin" (for example, real time systems), providing the necessary services and thereby supporting the execution of POSIX-compliant applications. It can be argued that following the POSIX standard makes it easier to port applications to almost any widely used operating platform. The extra effort put into improving mobility during the development phase will certainly pay off. By defining the interface to system services, POSIX leaves their implementation out of consideration. In particular, they do not differ system calls And library functions. Products are not subject to standardization administration, hardware limitations and features required only superuser, which once again emphasizes the focus of the POSIX standard on applications, not operating systems. POSIX is neutral with respect to system architecture and processor bit size. This is very important aspect application mobility. The focus on the international standard of the C language determined not only the style of describing functions, but also, to some extent, the direction of development of the POSIX specifications in terms of synchronization of both standards. As is known in the edition of the C language specifications approved in 1999 (see) it is legalized complex type data, which caused a corresponding replenishment of POSIX functions. The POSIX standard differentiates between required and optional functions, with the required core being kept as compact as possible. Of course Special attention focuses on ways to implement standardized functions both in the “classic” Unix environment and on other operating platforms, in network and distributed configurations. The developers of the new version of the POSIX standard were very careful about its prehistory, and the prehistory of Unix systems, and, most importantly, to applications that satisfied more earlier versions standard We tried to preserve the existing interfaces; in the development process the principle was observed backward compatibility; new interfaces were added so that they did not conflict with the old ones. It was not possible to completely avoid making changes to applications for obvious reasons: it was necessary to eliminate contradictions between different original specifications, as well as abandon support for the “traditional” version of the C language and switch to its international standard.

Basic concepts of the POSIX standard

The POSIX standard, as amended in 2003, is a very extensive, multifaceted document that covers in detail the following categories of system components:

development tools;

network tools;

real time tools;

control flows;

math interfaces;

package services;

header files;

legacy interfaces.

It is precisely this (at the top level, far from complete) repertoire that the operating system must provide for the application to work. The most important concept is POSIX compliance. We have already noted that every interface has two sides: the calling one and the called one. There are two sides to POSIX compliance: compliance with the implementation (operating system) and application. An implementation (operating system) that complies with the POSIX standard must support all required utilities, functions, header files, and provide the behavior specified in the standard. The _POSIX_VERSION constant has the value 200112L. The OS may provide features marked as optional in the standard, and may also contain non-standard features. If an extension is claimed to be supported, it must be done in a consistent manner, for all required parts, and in the manner described in the standard. In the header file You should define constants that correspond to the optional capabilities that are supported (for example, the constant _POSIX2_C_DEV serves C development tools). By analyzing these constants at compile time, the application will figure out the capabilities of the operating system being used and adapt to them. Similar runtime actions can be performed using the sysconf() function and/or the getconf utility. To minimize the size of the OS and applications, the POSIX standard provides for a very fine granularity of optional capabilities (forty in total). On the other hand, interrelated optional capabilities have been combined into groups, which in many cases eliminates the need to analyze a large number of options. These groups are:

encryption ;

real-time tools;

advanced real-time tools;

real-time streams;

advanced real-time streams;

trace ;

STREAM;

inherited capabilities.

For example, the "real-time facilities" group (_XOPEN_REALTIME) includes fourteen types of capabilities, including priority-based scheduling, asynchronous I/O, semaphores, timers, etc. Linux OS version on which the text was prepared this course, produced the following values for some configuration constants (see Listing 1.1).

$ getconf _POSIX_VERSION 199506 $ getconf POSIX2_C_DEV 1 $ getconf _XOPEN_REALTIME 1 $ getconf _POSIX_TRACE undefined Listing 1.1. The result of applying the getconf utility to one of the Linux OS versions.

This means it is supported outdated version POSIX standard, among others, there are development tools and real-time capabilities; There are no tracing tools. The OS documentation should reflect compliance issues with the POSIX standard and describe supported additional and non-standard features. For applications, the concept of POSIX compliance is more nuanced. Provided strict compliance, the main distinguishing feature of which is the limitation of the range of capabilities used within the framework of the standard. Compliance using extensions is also considered; in this case, the application documentation must contain a description of the required standard features. It is desirable that the POSIX feature extensions used are described by international and/or national standards. (Note that for implementation, the concept of strict POSIX compliance is meaningless, if only for the reason that there are no operating systems without administration tools, and they are not described by this standard.) We will call a profile a set of options that describe optional capabilities. Compliance with the profile means compliance with the POSIX standard and support of the specified capabilities. Profiles that are chosen wisely allow the needs of representative classes of users and/or applications to be addressed. It is possible to have "sub-profiles" that describe subsets of standard capabilities. An implementation corresponding to a subprofile may run on resource-constrained hardware platforms and/or serve the needs of specific applications. Among the most important are the concepts that describe the behavior of the implementation in various situations. For many correct situations, the behavior is unspecified, which means that a mobile application should not rely on the behavior of different implementations to match. For incorrect situations, the behavior may be undefined; Not only should an application not rely on the specific nature of such behavior, it should not perform inappropriate actions that cause undefined behavior. Another related term, " implementation dependent behavior", additionally means that the behavior of the implementation must be documented. The POSIX standard is a long-standing, evolving organism, in which with each new edition something is added and something is lost. Deprecated features are those that are still supported by various implementations, but they are likely to die out in the future. New applications should not use them; for each of them, the standard provides adequate modern replacements. A more limited meaning is given to the term "legacy": it describes obsolete optional features that, of course, should be avoided in new ones. applications.

Basic concepts of POSIX operating systems

We will cover the following basic concepts of POSIX operating systems:

user ;

file ;

process ;

terminal ;

host ;

network node;

time ;

linguistic and cultural environment.

These are primary concepts. They cannot be strictly defined, but can be explained using other concepts and relationships. For each of the highlighted concepts, their inherent attributes and operations applicable to them will be described. The text of the POSIX standard contains the following explanations of basic concepts along with references to attributes and operations.

The user has a name and a numeric ID.

A file is an object that can be read and/or written and has attributes such as permissions and type. The latter include regular file, character and block special files, pipe, symbolic link, socket and directory. An implementation may support other file types.

A process is an address space along with the threads of control running in it, as well as system resources, which these threads require.

A terminal (or terminal device) is a character-based special file that follows the specifications of the general terminal interface.

A network is a collection of interconnected hosts.

The linguistic-cultural environment is part of the user environment, depending on linguistic and cultural conventions.

To work with a large number of entities, mechanisms for grouping and building hierarchies are always provided. There is a hierarchy of files, groups of users and processes, subnets, etc. To write programs that operate with entities of POSIX-compatible systems, a command interpreter (shell language) and/or compiled language C is used. In the first case, the application can use utility programs (utilities), in the second - functions. Functional interface It is natural to consider operating systems to be primary, since most utility programs are designed, in fact, to call one or another function. For this reason, in what follows we will primarily consider the function level. The main operations applicable to OS objects are read, write and execute. The access rights mechanism allows you to selectively allow and prohibit such operations. Previously, the standard included the concept of a superuser, not subject to access control. POSIX-2001 chose a more flexible formulation - "having appropriate privileges", which reflects progress in the implementation of operating systems with split superuser capabilities. POSIX-compliant operating systems define objects that can be called auxiliary; they help organize interaction between the main entities. The range of tools is especially wide interprocess communication. Processes are performed in a specific environment, part of which is the linguistic and cultural environment (Locale), formed by such categories as symbols and their properties, message formats, date and time, numerical and monetary values. Typically there are at least three files associated with a process - standard input, standard output, standard protocol. Typically, standard input is assigned to the terminal keyboard, and standard output and standard protocol are assigned to the screen. Commands and (sometimes) the source data for them are read from standard input. The standard output receives the results of command execution. Diagnostic messages are placed in the standard protocol. Operating systems may have qualitative requirements, for example, the requirement for real-time support: the ability to provide the necessary service within a given period of time.

Compilation environment for POSIX-compliant applications

As a rule (although this is not always realized), application development is carried out cross-mode, that is, development platform (the equivalent term is tool platform) is not the same as the runtime platform (also called target platform). Created on the tool platform application compilation environment, so that the result of the compilation can be transferred for subsequent execution on the target platform. The most important part of the compilation environment are the header (or include) files containing function prototypes, definitions symbolic constants, macros, data types, structures, etc. Each function described in the POSIX standard specifies which header files must be included by the application that uses it (usually one file is required). It was stated above that through symbolic constants defined in the header file , the operating system provides the application with information about supported capabilities. The POSIX standard provides a symmetric mechanism called the feature check macros, it allows applications to advertise their desire to access certain prototypes and names. The main capability checking macro is _POSIX_C_SOURCE . Requirements for strictly POSIX-compliant applications include defining the symbolic constant _POSIX_C_SOURCE with a value of 200112L before including any header files. Thus, a POSIX-compliant application declares that it requires POSIX names. A similar role is played by the _XOPEN_SOURCE macro (with a value of 600 ). An example of using the _POSIX_C_SOURCE macro in include files The Linux OS can serve as the fragment shown in Listing 1.2.

#if defined(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L) #define LIBXML_THREAD_ENABLED#endif Listing 1.2. An example of using the _POSIX_C_SOURCE capability check macro.

The POSIX standard provides some measures to address the important and difficult problem (caused primarily by the non-objective nature of the C language) that there is no name overlap between the application and the operating system. The prefixes posix_, POSIX_ and _POSIX_ are reserved for the needs of the standard. Only system (not application) names can begin with an underscore followed by another underscore or a capital letter. For included files, the prefixes of the names used in them are described. For example, for file management operations appearing in , F_ , O_ , S_ are used as prefixes. The interprocess communication tools described in the file , the prefix is IPC_ . Unfortunately, there are a lot of header files, and there is no general naming discipline due to historical reasons. So, to manipulate the characteristics of the terminals in the file many different names are defined: EXTB, VDSUSP, DEFECHO, FLUSHO, etc. There are also four hundred and seventeen names like _Exit, abort, abs, acos, etc., which can be used for editing external relations application program. As a result, application programmer may accidentally “interrupt” a system macro, external variable or function, so it is advisable to use all the diagnostic tools of the compilation environment and carefully study the messages they produce.

Portability of POSIX-compliant applications

Portability of POSIX-compliant applications is fundamentally achievable due to two main factors. Firstly, the presence of a huge number of standardized system services, and secondly, the ability to dynamically determine the characteristics of the target platform and adjust the application to them. (Of course, we mean mobility within the framework regulated by the standard.) Applications that comply with the POSIX standard can be single- or multi-process, with the ability to dynamically adapt the configuration to the properties of the target platform. The means of generation and completion of processes, changing their programs, polling and/or changing various characteristics. Processes can be paused and reactivated at specified times. The signal mechanism allows you to notify about events and terminate processes externally. There are means for grouping them job management. The applications are equipped with controls to control scheduling and process priorities. Wide range of interprocess communication tools ( message queues, shared memory, semaphores) and memory management. Finally, multiple threads of control can be organized within a process. The necessary degree of execution determinism is achieved thanks to real-time support tools (these include processor allocation discipline control, real-time signals, page retention in RAM, high-resolution timers, etc.). Functions for working with files satisfy the needs of applications to read and write long-term data and protect such data from unauthorized access. Mechanism blocking file fragments allows you to ensure atomicity of transactions. Asynchronous I/O makes it possible to combine exchange operations, thereby optimizing applications. Complex data processing can be done with relative ease using a variety of utility programs. The POSIX standard carefully considers issues of access to external devices connected via serial lines, especially to terminals. Perhaps tools for working with such common media as magnetic tape need more detail. Standardized command language shell is an adequate tool for writing small mobile procedures and their fast interactive debugging. Let us highlight the pipeline mechanism, which allows you to combine commands into chains with filtering intermediate results. Utilities provide a rich execution environment for shell procedures. Due to the background mode, you can organize the simultaneous execution of several programs and interaction with them through a regular terminal without multi-window capabilities (however, windows would certainly not hurt). POSIX standardizes command line interface. In principle, it is sufficient, moderately convenient and, importantly, creates a minimum of problems in terms of mobility. It is likely that future versions of the standard will regulate GUI, but, of course, this is fraught with additional difficulties for mobile application developers. The linguistic and cultural environment is one of the most important concepts of the POSIX standard from a mobility point of view. Applications are able to detect the environment they need and adapt to the needs of users. Multi-user systems require the organization of interaction between a large number of people. POSIX solves this problem by regulating the means of direct and postal exchange of information. The POSIX standard provides basic facilities development support (primarily for the C language), which, of course, does not reduce the need for specialized, developed systems when it comes to working with really large software projects. Applications are provided with a standardized means to ascertain both large-block characteristics of the target system (for example, the range of optional features supported) and smaller-scale characteristics (the current amount of free disk space). The problem of application mobility is extremely complex, and it would be an exaggeration to say that the POSIX-2001 standard solves it completely. Firstly, such important issues as graphics, multi-window interface and whole line others. Secondly, there are “white spots” in regulated areas unspecified behavior implementations. However, let us emphasize this again, adherence to the POSIX standard is a mandatory element of the modern application systems development discipline.