What is posix. History of software development

Useful tips

The name Posix comes from "Portable" Operating System Interface", which roughly means "portable operating systems interface". This is not one standard, but a whole family developed by the Institute for Electrical and Electronics Engineers (IEEE). The Posix standards have also been adopted as international standards by ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission), or ISO/IEC. The Posix standards have gone through several stages of development.

IEEE Standard 1003.1-1988 (317 pages) was the first Posix standard. It defined the interface between the C language and a Unix-type kernel in the following areas: primitives for implementing processes (fork, exec calls, signals and timers), the process environment (user IDs, process groups), files and directories (all I/O functions) , working with the terminal, system databases (password and group files), tar and cpio archive formats.

NOTE

The first Posix standard was released in working form under the name IEEEIX in 1986. The name Posix was suggested by Richard Stallman.

Then the IEEE 1003.1-1990 standard (356 pages) came out. It was also the international standard ISO/IEC 9945-1:1990. Compared to the 1988 version, changes in the 1990 version were minimal. "Part 1: System Application Program Interface (API)" was added to the title, indicating that the standard described software interface(API) of the C language.

IEEE 1003.2-1992 came in two volumes totaling about 1300 pages, and its title contained the line "Part 2: Shell and Utilities." This part defined the interpreter (based on the Bourne shell in Unix System V) and about a hundred utilities (programs typically called from the interpreter - from awk and basename to vi and uass). In this book we will refer to this standard under the name Posix. 2.

IEEE 1003.1b-1993 (590 pages) was originally known as IEEE P1003.4. This standard was an addition to the 1003.1-1990 standard and included real-time extensions developed by the P1003.4 working group: file synchronization, asynchronous I/O, semaphores, memory management, scheduling, clocks, timers, and message queues.

IEEE 1003.1, 1996 edition (743 pages), includes 1003.1-1990 (Base API), 1003.1b-1993 (Real-Time Extensions), 1003.1-1995 (Pthreads - Posix Program Threads), and 1003.1i-1995 (Technical Amendments to 1003.1b). This standard is also called ISO/IEC 9945-1: 1996. It added three chapters on threads and additional sections on thread synchronization (mutuals and condition variables), thread scheduling, synchronization scheduling. In this book we call this standard Posix.1.

NOTE

More than a quarter of the standard's 743 pages were an appendix entitled "Rationale and Notes." This rationale provides historical information and an explanation of the reasons why certain features were or were not included in the standard. Often the rationale is no less useful than the standard itself.

Unfortunately, IEEE standards are not freely available via the Internet. Information on where you can order the book is given in the bibliography under the link. Note that semaphores were defined in the Real-Time Extensions standard, separate from mutexes and condition variables (which were defined in the Pthreads standard), which explains some of the differences in API interfaces these funds.

Finally, note that read-write locks are not part of the Posix standards. This is covered in more detail in Chapter 8.

In the future, a new version of IEEE 1003.1 is planned, including the P1003.1g standard, network interfaces (sockets and XTI), which are described in the first volume of this book.

The Preface of the 1996 Posix.1 standard states that ISO/IEC 9945 consists of the following parts:

1. System program development interface (API) (C language).

2. Interpreter and utilities.

3. System administration (in development).

Parts 1 and 2 are what we call Posix.1 and Posix.2.

Work on the Posix standards is ongoing, and the authors of books related to them have to deal with shooting at a moving target. The current status of the standards can be found at http://www.pasc.org/standing/sd11.html.

STANDARDS

Sergey Zolotarev,

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 of 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 port ready code at the source text level, both from their past or parallel projects, and from projects of third companies. 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 traces its history 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 rather means “specification”, which is more consistent with the status of documents adopted 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; www.pasc.org/), an association committee that develops the POSIX family of standards. PASC was formerly known as the Operating Systems Technical Committee.

The second participant in the work is ANSI (American National Standards Institute, American National Standards Institute; www.ansi.org) - a private non-profit organization that 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. 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; www.iso.org). 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. ISO is a network of national standardization institutes 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; www.iec.ch/), founded in 1906, the IEC prepares and publishes international standards for all electrical, electronic and related technologies. 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- a 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 it is intended that an IEC document become only a technical specification and not 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 vendors and user communities working in the field of information technology (www.opengroup.org/).OpenGroup 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/).

AustinCommonStandardsRevisionGroup (CSRG)- a joint technical working group formed in 2002 by ISO, IEC and Open Group to create and maintain latest versions standard 1003.1, which will be based on 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 (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 systems 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 to POSIX, and the next publication (back in 1986) used this new variant. 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 mechanism for interaction between an application program and the OS and currently includes more than 30 standards under the auspices of IEEE, ISO, IEC and ANSI.

POSIX has come a long way throughout its history, with numerous changes to the designation of 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 finalize the base text changes after the IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b standards were completed.

- 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, but only three have received widespread support in commercial operating systems:

1003.1a (OS Definition) defines basic OS interfaces, job control, signals, functions file system and working with devices, 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 support functions for threads (threads) - thread management, thread attributes, mutexes, dispatching. Originally designated as 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, operating system must be certified based on the results of an appropriate set of tests. 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 option 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 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(tm) 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 the full certification procedure, meets all requirements based on testing results, and is included in the official register of 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:

Сompatibility (literally - “compatibility”);

Сompliance (literally - “compliance”);

Сonformance (literally “consistency”).

The first term, as applied to POSIX, is not formally defined. The second means that the organization producing the software product independently declares that this product (fully or partially) complies with the listed NIST-PCTS standards. The third term implies that the software product has passed installed system tests either with the help of an accredited laboratory or within the Open Group and there is documentary evidence for 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 adhere 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 level conformance, then currently there are only two certified RT OS (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 the development of hard real-time embedded systems software by OEMs and telecommunications equipment manufacturers, particularly military airborne system manufacturers. . 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 (target). LynxOS v.3 is certified for consistency (conformance) POSIX standard on 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 for the NIST FIPS 151- test suite. 2 Conformance Test Suite. Certification document number: Reference File: IP-2LYX002, Reference File: IP-2LYX001.

- INTEGRITY v.5(product of Green Hills Software, www.ghs.com) certified for consistency (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) certified for compliance (compliance) according to 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

1. IEEE Standards Association Operation Manual. IEEE, October 2004.

2. Kevin M. Obeland. POSIX in Real-Time, Embedded Systems Programming, 2001.

3. IEEE/ANSI Standard 1003.1: Information Technology - (POSIX) - Part1: System Application: Program Interface (API).

4. Gallmeister B.O. Programming for the Real World, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.

5. National Institute of Standards and Technology, PCTS:151-2, POSIX Test Suite.

6. POSIX: Certified by IEEE and The Open Group. Certified Policy. The Open Group, October 21, 2003, Revision 1.1.

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?

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

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) is a private non-profit organization that 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 of national standardization institutes 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.

The IEC is the key organization in the preparation of international information technology standards. 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 everything from software to programming languages, computer graphics and image editing, hardware interconnections and security techniques.

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 systems 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 version was used 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 a standard mechanism for interaction between an application program and an operating system and currently includes more than 30 standards under the auspices of IEEE, ISO, IEC and ANSI.

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 finalize the base text changes after the IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b standards were completed.

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. Initially (until 1993) this standard was 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 option 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".

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 the full certification procedure, meets all requirements based on testing results, and is included in the official register of 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 (mandatory parts only);
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).

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

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 the software product has passed an established test system 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 we adhere to strict rules requiring that data on a certified RT OS be published in an official register and testing be carried out at the conformance level, then at present 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 the development of hard real-time embedded systems software by OEMs and telecommunications equipment manufacturers, particularly military airborne system manufacturers. . 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 (target). 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 the Intel platform 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 the following POSIX family standards (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.

Subject: Operating systems.
Question: No. 8

—————————————————————

OS design principles:

1.) The principle of modularity– in the general case, a module is understood as a functionally complete element of the system, made in accordance with accepted intermodular interfaces. By its definition, a module assumes the ability to easily replace it with another if the specified interfaces are available. To a large extent, the division of the system into modules is determined by the OS design method used (bottom-up or vice versa).

Of particular importance when building an OS are privileged, reentrant and reentrant modules (reentrant - literally reentrant; a special term to denote the operability of a program; the property of a program to be executed correctly when called recursively (returned) from an interrupt).

The greatest effect from using this principle is achievable if this principle is simultaneously distributed to the OS, application programs and hardware.

2.) The principle of functional selectivity– the OS allocates a certain part of important modules that must be permanently located in RAM for more efficient organization of the computing process. This part of the OS is called the kernel, since it is the basis of the system. When forming the composition of the core, two contradictory requirements have to be taken into account. On the one hand, the kernel should include the most frequently used system modules, on the other hand, the number of modules should be such that the amount of memory occupied by the kernel is not too large. In addition to the program modules that are part of the kernel and are permanently located in RAM, there may be many other system program modules, which are called transit. Transit software modules loaded into RAM only when necessary and in case of absence free space can be replaced by other transit modules.

3.) OS generation principle: The essence of the principle is to organize (select) such a method of the initial representation of the central system control program of the OS (the kernel and the main components permanently located in RAM), which made it possible to configure this system supervisory part based on the specific configuration of a particular computing complex and the range of tasks being solved. This procedure is rarely carried out before a fairly long period of operating the OS. The generation process is carried out using a special generator program and the corresponding input language for this program, which allows you to describe the software capabilities of the system and the configuration of the machine. As a result of generation, a full version of the OS is obtained. The generated OS version is a collection of system sets of modules and data.

4.) The principle of functional redundancy: This principle takes into account the possibility of carrying out the same work by different means. The OS may include several types of monitors (supervisor modules that manage one or another type of resource), various means of organizing communications between computing processes. The presence of several types of monitors and several file management systems allows users to quickly and most adequately adapt the OS to a specific computer system configuration and ensure the most efficient loading technical means when solving a specific class of problems, obtain maximum performance when solving a given class of problems.

5.) Principle of virtualization: the construction of virtual resources, their distribution and use is currently used in almost any OS. This principle allows you to present the structure of the system in the form of a certain set of process schedulers and resource allocators (monitors) and use a single centralized scheme for resource distribution.

The most natural and complete manifestation of the concept of virtuality is the concept virtual machine. The virtual machine provided to the user reproduces the architecture of the real machine, but the architectural elements in this representation appear with new or improved characteristics, usually simplifying work with the system. The characteristics can be arbitrary, but most often users want to have their own “ideal” machine in terms of architectural characteristics, consisting of the following:

— virtual memory of practically unlimited capacity, uniform in operating logic.

— an arbitrary number of virtual processors capable of working in parallel and interacting during operation.

— an arbitrary number of external virtual devices capable of working with the memory of a virtual machine in parallel or sequentially, asynchronously or synchronously with respect to the operation of a particular virtual processor that initiates the operation of these devices.

One of the aspects of virtualization is the organization of the ability to run applications on a given OS that were developed for other OSs. In other words, we are talking about organizing several operating environments.

6.) The principle of program independence from external devices: This principle is now implemented in the vast majority of general operating systems. For the first time, this principle was most consistently implemented in the UNIX OS. It is also implemented in most modern PC operating systems. This principle is that the connection of programs with specific devices is not carried out at the level of broadcasting the program, but during the planning period for its execution. As a result, recompilation is not required when running the program on a new device on which the data is located.

7.) Compatibility principle: One aspect of compatibility is the ability of the operating system to run programs written for other operating systems or for more earlier versions this OS, as well as for other hardware platforms. It is necessary to separate questions binary compatibility And source-level compatibility applications.

Binary compatibility is achieved when you can take executable program and run it on another OS. This requires compatibility at the level of processor instructions, and compatibility at the level system calls, and even at the library call level if they are dynamically linked.

Compatibility at the source level requires the presence of an appropriate translator as part of the system software, as well as compatibility at the level of libraries and system calls. In this case, it is necessary to recompile the existing source texts into a new executable module.

It is much more difficult to achieve binary compatibility between processors based on different architectures. In order for one computer to execute the programs of another (for example, it is advisable to execute a program for a PC such as an IBM PC on a PC such as an Apple Macintosh), this computer must work with machine instructions that are initially incomprehensible to it. In this case, a 680x0 type processor (or PowerPC) must execute binary code, designed for i80x86 processor. The 80x86 processor has its own instruction decoder, registers, and internal architecture. A 680x0 processor does not understand 80x86 binary code, so it must fetch each instruction and decode it to determine what

what it is intended to do, and then execute the equivalent routine written for 680x0.

One of the means of ensuring compatibility between software and user interfaces is compliance with POSIX standards, the use of which allows you to create UNIX-style programs that can be easily transferred from one system to another.

8.) The principle of openness and scalability: An open operating system is available for analysis by both users and system specialists maintaining the computer system. An extensible (modified, developed) OS allows you not only to use generation capabilities, but also to introduce new modules into its composition, improve existing ones, etc. In other words, it should be possible to easily make additions and changes when necessary without compromising the integrity of the system. Excellent opportunities for expansion are provided by the client-server approach to structuring the OS using micro-kernel technology. In accordance with this approach, the OS is built as a set of privileged control programs and a set of unprivileged services (servers). The main part of the OS remains unchanged, and at the same time new servers can be added or old ones improved. This principle is sometimes interpreted as system expandability.

9.) Mobility principle: the operating system should be relatively easy to port

transfer from a processor of one type to a processor of another type and from a hardware platform of one type, which includes, along with the type of processor, the method of organizing all computer hardware (computer system architecture), to a hardware platform of another type. Note that the principle of portability is very close to the principle of compatibility, although they are not the same thing. Creating a portable OS is similar to writing any portable code, but you need to follow some rules:

— most of the OS must be executed in a language available on all systems to which it is planned to be transferred in the future. This, first of all, means that the OS must be written in a high-level language, preferably a standardized one, such as C. A program written in assembly language is generally not portable.

- It is important to minimize or, if possible, eliminate those parts of the code that directly interact with the hardware. Hardware dependence can take many forms. Some obvious forms of dependency include direct manipulation of registers and other hardware. Finally, if hardware-dependent code cannot be completely eliminated, then it should be isolated in several well-localized modules. Hardware-dependent code should not be distributed throughout the system. For example, you can hide a device-dependent structure in program-defined data of an abstract type.

The introduction of POSIX standards was intended to ensure portability of the software being created.

10.) Computing security principle: ensuring security when performing calculations is a desirable property for any multi-user system. Security rules define properties such as protecting one user's resources from others and setting resource quotas to prevent one user from taking over all system resources, such as memory.

Ensuring the protection of information from unauthorized access is a mandatory function of network operating systems.

—————————————————————

What's happenedPOSIX: platform-independent system interface for computer environments POSIX (Portable Operating System Interface for Computer Environments) is an IEEE (Institute of Electrical and Electronics Engineers) standard that describes system interfaces for open operating systems, including shells, utilities and tools. In addition, according to POSIX, security tasks, real-time tasks, administrative processes, network functions and transaction processing are standardized. The standard is based on UNIX systems, but can also be implemented in other operating systems. POSIX arose as an attempt by the world-renowned IEEE to promote application portability in UNIX environments by developing an abstract, platform-independent standard. For example, the well-known QNX real-time OS complies with the specifications of this standard.

This standard describes in detail the virtual memory system VMS (Virtual Memory System), multitasking MPE (Multi-Process Executing) and technology for transferring operating systems CTOS (An Operating System produced Convergent Technology ...). So POSIX is actually a set of standards called POSIX.I through POSIX.12. It should also be especially noted that POSIX.1 assumes C as the main language

description language system functions API.

Thus, programs written to these standards will run the same on all POSIX-compliant systems. However, in some cases the standard is only advisory in nature. Some of the standards are described very strictly, while others only superficially reveal the basic requirements.

Implementations of the POSIX API at the operating system level vary. While the vast majority of UNIX systems initially comply with IEEE Standard 1003.1-1990 specifications, then WinAPI is not POSIX-compatible. However, to support this standard, the MS Windows NT operating system introduced a special POSIX API support module that operates at the privilege level of user processes.

This module provides conversion and transfer of calls from user program to the system kernel and back, working with the kernel via the Win API. Other applications built using WinAPI can pass information to POSIX applications via standard I/O stream mechanisms (stdin, stdout).

There are no similar posts...

About standards in general

There is an opinion among practicing programmers that standards in programming are not needed at all, because:

(1) they are inherently meaningless, since their authors do not write computer programs;

(2) they hinder programmers' initiative;

(3) programmers will always agree even without standards.

Perhaps this opinion should not have been paid attention to if not for two circumstances:

(1) it is expressed by practitioners, that is, precisely those who “produce software products”;

(2) The above argument was discovered by the author of this article in one of the publications on the Internet dedicated to the standard for the C programming language, from which it became clear that such an opinion is widespread “on an international scale”, and not just among arrogant Russian “superprogrammers”.

The word “standard” is usually associated with something material (standard dimensions, standard electrical voltage, etc.), while computer program- an intangible object (“ The new intangible"), and maybe standards in the intangible sphere are really meaningless?

There is, however, a refuting example. The set of spelling rules of the Russian language essentially represents a standard, although not approved by standardization bodies. Further, in addition to the rules (or, if you like, requirements) of spelling, there are syntactic rules and, most importantly, semantics. The latter illustrates well the “children’s” question: why is a cat called a cat? There is a precise answer to this question: because our ancestors agreed so; the ancestors of the English agreed to call the same animal cat, the ancestors of the Germans - kitten, etc. And in general, the meaning, or semantics, or rules of interpretation of any word or combination of words is a matter of agreement.

Purpose and “super task” of the POSIX standard

As the name suggests, POSIX (Portable Operating System Interface) is a standard for the interface between an operating system and an application program. The days when programmers wrote programs for a “bare” machine (implementing their own packages of input/output programs, trigonometric functions, etc.) are gone forever. The POSIX text repeatedly emphasizes that the standard does not impose any requirements on operating system implementation details; it can be viewed as a set of agreements between application programmers and operating system developers. Thus (again, contrary to a fairly widespread belief), POSIX is of interest not only to operating system developers, but primarily to a much larger category of application programmers.

The need for a standard of this kind was recognized back in the 1980s, when UNIX operating systems became widespread. It turned out that although this system was intended to be unified, differences between its specific implementations led to the fact that application programs written for one system could not always be executed in another. It is this problem, known as the software mobility problem, that POSIX aims to solve. The first edition of the standard was released in 1988 (there is a translation, see), in which the whole variety of issues related to software mobility was divided into two parts: (1) application program interface, (2) command interpreter and utilities (user interface ); these parts are called POSIX.1 and POSIX.2, respectively1.

Let us clarify that in this article we will only talk about the application program interface standard, POSIX.1, the second (and to date) edition of which was approved on July 12, 1996.

The informative part of the standard also emphasizes that POSIX is not a description of the interface of some “ideal” operating system, but the result of a generalization and systematization of the experience accumulated in the development of UNIX operating systems. In addition, POSIX cannot serve as a manual or tutorial on operating systems, although the informative part contains recommendations for programmers and program fragments.

The standard directly states that it is impossible to create a full-fledged operating system based solely on the interface functions described in it. (In particular, POSIX.1 does not address issues such as networking and related interface functions or graphical interfaces.) However, the financial costs of non-portable software and the resulting need for interface unification are so great that most manufacturers prefer to have at least some standard is better than to have none. For this reason, many software developers strive to focus on POSIX. This allows, if not eliminating the immobility of programs completely, then at least significantly reducing the immobile part of the program.

About semantics

As already discussed, POSIX can be thought of as a set of agreements between the operating system developer and the application programmer. “Agreement” means, first of all, the same interpretation (semantics) of words and expressions. The following are examples that illustrate the difficulty of reaching an “agreement.”

How to convey meaning when translating

First of all, it should be recalled that the POSIX standard is written in English, which by its nature provokes ambiguities (for example, the same word can be a noun, an adjective and a verb), and “semantic traps” lurk on almost every page. A good illustration of this is an example from fiction. One of the most famous works of Oscar Wilde, who brilliantly used this feature of the English language, The Importance of being Earnest, is known in Russian under the title “The Importance of Being Earnest.” However, the English title has a second meaning: Earnest (serious) is the surname of one of the characters, and the title could be translated differently: “The importance of being Ernst.” There is a Russian surname Serebryany, and if there was a surname Serezny, the translation would be perfectly accurate, conveying both meanings.

The situation is similar with the name of the standard itself: Portable Operating System Interface. The adjective Portable (mobile) refers to both the operating system and the application program, but it is not possible to express it as briefly in Russian; it can be translated as “Interface of a mobile operating system” or “Interface of an operating system that ensures the mobility of application programs.” The second option better reflects the intentions of the developers of the standard, but the first meaning is lost (the more familiar first option was preserved during translation).

Semantics of the word “standard”

The main text of the standard is preceded by a preamble, which explains the meaning of the words IEEE Standards2. As follows from these explanations, there are at least three semantic differences from the Russian-language term GOST:

(1) Intuitively, it is believed that GOST has the force of law, the violation of which is punishable; POSIX is a set of requirements, adherence to which is entirely voluntary.

(2) GOST is valid until its cancellation (many people have probably heard the expression “GOST has not been canceled”); the preamble to POSIX states that if a standard has not been revised for 5 years, the issues it addresses are likely to be no longer relevant and it can be considered automatically repealed;

(3) GOST is anonymous; the POSIX preamble provides a list of those who contributed to the development of the standard and provides an address to which requests for interpretation can be made; it is also said that the response to each request is subject to an agreement procedure (in other words, the authors of the standard agree among themselves before giving a response).

Thus, the translation of even such a well-known word as Standard with the word “standard” requires comment.

Semantics of the words “must”, “not specified”, “undefined”, “implementation defined”

Section 2 of the standard is called “Terminology and General Requirements.” It contains definitions not only of technical terms (like “process” or “semaphore”), but also of such seemingly self-evident words as “should” or “can”. Since POSIX.1 is an interface standard, its requirements apply to both the operating system and the application program. An explicit requirement is expressed by the word "shall", for example: "If successful, the link() function must return a null value." IN in this example This is a requirement for the operating system: the link() function must be implemented so that it returns a null value upon successful completion.

The terms “unspecified” and “undefined” express the same idea that the standard allows for freedom of choice, but the meaning of these terms is different. The term “not specified” implies that we are talking about some correct actions (actions, program constructs, etc.), and the term “not defined” means incorrect (erroneous) ones. The informative part of the standard provides the following explanation.

The term "unspecified" means that the set of options (outcomes, results of a function call, etc.) is assumed to be known, and the standard allows any of them; in a particular operating system implementation, any one can be chosen, and such a system is considered to comply with the standard. The application program (which strictly complies with the standard) must be written in such a way that it works correctly under any option; Essentially, this term implicitly expresses a requirement for an application program.

Here's an example: “The readdir() function must return a pointer to a structure related to the next directory element. Whether directory elements named "dot" and "dot-to-dot" are returned is not specified by the standard." In this example, there are four possible outcomes, and the requirement for the application program is that it must be able to handle any of them.

Another example: “If the sigwait() function, which instructs to wait for a signal with the specified number, is called in several control threads, then when a signal arrives in no more than one of them, sigwait() must return. In what exact control flow this will happen is not specified by the standard.” In this example, the number of possible outcomes may be larger, but they are all known, and the requirement for the application program is that it must work correctly under any outcome.

The term “undefined” implies that even many outcomes are not known; any outcome is possible, even disastrous ones (for example, system crash, data loss, etc.). Essentially, this term implicitly requires the application program not to use the corresponding data or constructs. For example: "If the dirp argument to readdir() does not refer to an open one in this moment directory, result undefined."

This example requires the application program to supply only a link to an open directory as an argument to readdir(); Violation of this requirement can lead to catastrophic consequences, and responsibility for this rests with the application programmer.

Here's another example: "If successful, the read() function should return an integer indicating the number of bytes actually read. Otherwise, the function must set errno to an error code and return -1, and the contents of the buffer pointed to by buf are undefined."

The standard prohibits the use of data from a buffer in an application program in the event of a read() function error, and the consequences of violating this requirement are borne by the application programmer.

The meaning of the term "implementation determined" is different from the intuitive one. Obviously, in a specific operating system there cannot be an “unspecified” or “undefined” result; some specific result will definitely be obtained. The term “implementation-defined” expresses the standard's requirement for operating system documentation: the result must not only be specified (the operating system developer will have to do this in any case), but also be explicitly reflected in the system documentation.

Default semantics

No regulatory document can cover the entire variety of cases that may occur in practice, so it inevitably holds something back3. For example, a function description might say that its argument can take values from a certain range, but nothing will say what the result will be if the argument does not fall within that range. Obviously, in order to avoid misunderstandings, it is necessary to have a unified default semantics. In the informative part of the standard there is an interesting phrase: “generally accepted semantics of default - prohibited.” This statement contradicts the well-known slogan of ten years ago “everything is permitted that is not explicitly prohibited.” Apparently, it is so ingrained in the minds of citizens that many, even programmers, do not agree with the quoted statement of the standard. Meanwhile, if the use of a construction is not clearly permitted and does not follow from the description, then any practicing programmer realizes that its use is risky, and if it does not work, it does not occur to him to make a claim.

Processes and threads of control

Both of these terms express the idea of parallel execution. operating room UNIX system was originally conceived as multi-user, and programs launched by different users must be reliably isolated from each other so as not to accidentally distort “other people’s” data. This isolation is ensured by the fact that the user program is executed within a process that runs in its own virtual address space. Even if the program has global data, when it is launched in different processes, they will be automatically “separated” into different address spaces.

However, the process mechanism is not entirely satisfactory for programming real-time tasks. A real-time application program (running on behalf of the same user) can often be naturally represented in the form of concurrently executing parts called “threads”. Their most significant difference from processes is that all control flows develop in a single address space; This provides quick access to global data, but at the same time there is a risk of unintentional distortion, and to avoid this, some programming discipline must be observed. Relevant recommendations are contained in the informative part of the standard.

It should be emphasized that the idea of multithreading is implemented in many real-time operating systems, and is implemented differently in the sense that each control flow has a different set of attributes and interface functions; sometimes the term “task” is used instead of the term “thread”. To avoid confusion, the standard emphasizes that it deals exclusively with POSIX control threads, and the names of the corresponding interface functions are prefixed with pthread_ (for example, pthread_create(), pthread_join(), etc.).

Compliance with standard. Semantics of the word “corresponds”

Intuitively, if two items are made to the same standard, then they are guaranteed to “mate” with each other and work together as a pair; This is precisely the purpose of introducing a standard for interfacing (interface). Since POSIX is an interface standard, we can talk about compliance with the standard of both the operating system and the application program.

The POSIX.1 standard contains several hundred (if not thousands) of requirements; It is considered self-evident that if at least one of these is not met, then the system (or application program) does not satisfy the standard. At the same time, so many UNIX-class operating systems and application programs for them have been written to date that it is hardly reasonable to demand full compliance in the specified sense. The difficulties of developing an international standard of this kind are compounded by the existence of different national languages. Even if we forget about application programs designed for processing texts in national languages, almost any application program must produce some kind of diagnostic messages and/or accept texts entered by the operator.

strict compliance with the POSIX.1 standard;
compliance with the international version of POSIX.1;
compliance with the national version of POSIX.1;
POSIX.1 compliance with extensions.

Secondly, many interface facilities are declared optional; the standard requires that optional interface functions either behave as specified by the standard or always return a special error code, ENOSYS (indicating that the function is not implemented). Optional facilities are divided into several groups, each of which has a corresponding configuration constant, which is declared (with the #define operator) in the corresponding header file; This makes it possible to determine whether a function is implemented at compile time.

The described technique for achieving mobility was not invented by the authors of POSIX, but has long been used in practice; Many operating systems use configuration constants to identify the system itself or its version. And here the standard does not offer anything fundamentally new, but only systematizes existing practice.

Objects of standardization and structure of the standard

In short, the objects of POSIX.1 standardization are names and semantics. More specifically, we are talking about the following.

Interface function names. 357 functions have been standardized, with 107 functions taken from standard C libraries (mathematical, string processing, input/output, etc.); these functions are considered part of the POSIX.1 standard, however they are Full description contained in the standard for the C programming language.
Names of system data types. These names have the suffix _t.
Names of header files, as well as the minimum composition of these files.
Names of system-wide global variables (for example, errno).
Symbolic names of error codes that can be set when executing functions. These names start with the letter E (EPERM, ENOTEMPTY, etc.).
Names of configuration constants. These names are prefixed with _POSIX_.
Symbolic names of signal numbers; these names are prefixed with SIG. In addition to 20 “traditional” signals (SIGABRT, SIGALRM, etc.), real-time signals have been standardized, the numbers of which must occupy a certain continuous range from SIGRTMIN to SIGRTMAX inclusive, containing at least RTSIG_MAX numbers.
Symbolic names corresponding to the values of individual arguments of some functions (for example, the cmd argument of the fcntl() function can take the values F_DUPFD, F_GETFD, F_GETLK, etc.).
Names of macros, constants, bit flags, environment variables.

In general, the standard consists of two large parts of approximately the same volume. The first half - the normative part - contains the requirements and recommendations of the standard (18 sections), the second - the informative part - contains Appendices, which provide a list of references, comments and explanations to the normative part, the composition of header files, an example of a profile (“projection”) of the standard ( for Denmark), characteristics and methodology for measuring the performance of the most important functions, as well as a description of additional interface functions for working with files in real time; It is expected that future editions of the standard will include these functions in the normative part.

An idea of what specific types of operating system services are covered by the standard is given by the sidebar “Summary of the sections of the standard.”

Conclusion

The main content of the POSIX standard is the semantics of interface functions. Standardizing semantics is not an easy task in itself (everyone knows how difficult it can be for even two people to agree), and the difficulties are aggravated by the fact that so many people are currently involved in programming activities. For example, the parallel execution paradigm is expressed in terms such as “process”, “task” and “control flow”, but from the point of view of practical programming, a “task” in the IBM OS/360 operating system and in the VxWorks real-time operating system is not the same thing. and also. Another example is semaphores. Semaphores can be binary, integer (“with a counter”) and mutual exclusion (which, by the way, programmers call among themselves “mutexes”, spontaneously trying to avoid misunderstandings). And integer semaphores, for example, in the VxWorks operating system, are not at all the same as POSIX semaphores.

The authors of the POSIX standard, fully aware of how difficult it is to get people to change their habits (which they call "established practice"), claim that they have compiled a logically coherent and minimal system of interface functions that cover most of the services traditionally provided by the operating system, in detail described the exact semantics of these functions and invite everyone to use them in their developments4.

When reading the standard, one sometimes gets the impression that some of the wording had a single purpose: not to remove any application programs or operating systems from the category of satisfying the standard. This goal was indeed set and explicitly formulated in the Introduction: the standard should take into account existing practice to the maximum extent possible. However, the main goal is still to ensure the mobility of application programs.

About the author

Sergey Romanyuk - Senior Researcher, Research Institute systems research, leader of the POSIX standard translators team. He can be contacted by email at: [email protected]

1 It should be added that work on the standard has been ongoing for many years; New issues are identified and they are either included in one of the existing parts or are issued as a separate part, which can later be canceled. This happened, for example, with real-time interfaces, which were first declared as POSIX.4 and later included in POSIX.1.

2 IEEE is the organization that developed the POSIX standard.

3 Here “default” means silent, not default; We are not talking about some implied meanings that are actually declared, but about the absence of references at all.

4 A translation of the standard into Russian will be published in early 2000.

Literature

International Standard ISO/IEC 9945-1 (ANSI/IEEE Std 1003.1) Second Edition. 1996-07-12. Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API).

M.I.Belyakov, Yu.I.Rabover, A.L.Friedman. Mobile operating system. Directory. Moscow, Radio and Communications, 1991.

ISO/IEC 9899: 1990, Programming languages - C.

Section 1	- Introduction
Section 2	- Terminology and definitions
Section 3	- Functions for managing processes (creation, image replacement, termination) and signals (managing masks, responding to signals)
Section 4	- Identification (processes, users, system, terminal), polling of the time spent on process execution, polling of environment variables.
Section 5	- File and directory management
Section 6	- Input and output functions
Section 7	- Terminal management functions
Section 8	- Functions borrowed from the C language standard
Section 9	- Access to user and user group databases
Section 10	- Data formats for archiving and sharing (tar and cpio)
Section 11	- Synchronization tools: semaphores, mutexes and condition variables
Section 12	- Memory management functions: pinning and unpinning process address space, memory mapping of files, memory protection, shared memory
Section 13	- Functions related to scheduling processes and control flows
Section 14	- Clock and timer management
Section 15	- Message queue management
Section 16	- Basic functions related to control flow
Section 17	- Thread-specific data
Section 18	- Tools for destroying control flows

What is posix. History of software development

POSIX and RT OS: an attempt at systematization

As an introduction: why is software interface standardization necessary?

Who's Who in POSIX Development

What is POSIX?

History of the development of the POSIX standard

The most important POSIX standards for RT OS

Certification procedure

A little about confusion in terminology

Certified OS RV

POSIX and the QNX operating system

About standards in general

Purpose and “super task” of the POSIX standard

About semantics

Compliance with standard. Semantics of the word “corresponds”

Objects of standardization and structure of the standard

Conclusion

About the author

Literature

Popular articles

Latest articles

Sections

Pages

Special projects

Contacts

What is posix. ﻿ History of software development

POSIX and RT OS: an attempt at systematization

As an introduction: why is software interface standardization necessary?

Who's Who in POSIX Development

What is POSIX?

History of the development of the POSIX standard

The most important POSIX standards for RT OS

Certification procedure

A little about confusion in terminology

Certified OS RV

POSIX and the QNX operating system

About standards in general

Purpose and “super task” of the POSIX standard

About semantics

Compliance with standard. Semantics of the word “corresponds”

Objects of standardization and structure of the standard

Conclusion

About the author

Literature

Popular articles

Latest articles

Sections

Pages

Special projects

Contacts

What is posix. History of software development