the main / Problems / UNIX Standardization of operating systems and POSIX. Standards of real-time operating systems

UNIX Standardization of operating systems and POSIX. Standards of real-time operating systems

About standards in general

Among practitioners programmers are the opinion that the standards in programming are not needed at all, since:

(1) They are initially meaningless, since their authors do not write computer programs;

(2) they are fighting the initiative of programmers;

(3) Programmers will always agree without standards.

Maybe this opinion should not be paid attention to if not two circumstances:

(1) His practices express, that is, it is those who "issues program products";

(2) The above argument was discovered by the author of this article in one of the publications in the Internet on the standard for the programming language of C, which it became clear that such an opinion was disseminated "on an international scale", and not only among arrogant Russian "superfrogramists".

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

There is, however, a refuting example. The combination of the rules of the spelling of the Russian language essentially is a standard, although not approved by standardization authorities. Further, except for the rules (or, if you, the requirements) of spelling, there are syntactic rules and, most importantly, semantics. The latter illustrates the "children's" question: why is the cat call a cat? There is an accurate answer to this question: because our ancestors agreed so; The ancestors of the British agreed to call the same beast Cat, the ancestors of the Germans - Kitten, etc. In general, the meaning, or semantics, or the rules for the interpretation of any word or a combination of words - the question of agreement.

Appointment and "Superbate" of the standard POSIX

As follows from the name, POSIX (Portable Operating System Interface) is a standard for pairing (interface) between the operating system and the application program. Times when programmers wrote programs for the "naked" machine (implementing their own packages of I / O programs, trigonometric functions, etc.), passed irretrievably. The text POSIX repeatedly emphasizes that the standard does not put forward any requirements for the operations of the operating system; It can be considered as a totality of agreements between application programmers and developers operating systems. Thus (again, contrary to a fairly popular opinion), POSIX is of interest not only for developers of operating systems, but first of all, for a much more numerous category of programmers - applied.

The need for the standard of this kind was realized in the 1980s, when the UNIX operating systems were widespread. It turned out that although this system was conceived as a unified, the differences between its specific implementations led to the fact that the application programs written for one system could not always be executed in another. On the decision of this particular problem, known as the problem of mobility software, POSIX aimed. The first edition of the standard was released in 1988 (there is a translation, see), in which all the variety of issues related to the program mobility was divided into two parts: (1) application interface, (2) Command Interpreter and Utilities (User Interface ); These parts were called POSIX.1 and POSIX.2, respectively1.

We will specify that this article will talk only about the standard for the application interface, POSIX.1, the second (and the last to date) 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 generalization and systematization of experience gained in the development of UNIX operating systems. In addition, POSIX cannot serve as a guide or training manual for operating systems, although the informative part contains recommendations to programmers and fragments of programs.

The standard refers to the fact that it is impossible to create a full-fledged operating system, focusing exclusively on the interface functions described in it. (In particular, POSIX.1 does not reflect such issues as networking and related interface functions or a graphical interface.) However, the financial costs caused by nongetability of programs and the need for the unification of the interface is so great that most manufacturers prefers Have at least some standard than have no one. For this reason, very many software developers seek to navigate on POSIX. This makes it possible if you do not eliminate the nonumatinity of programs completely, then at least significantly reduce the nongetable part of the program.

About semantics

As already mentioned, POSIX can be considered as a set of agreements between the developer of the operating system and the application programmer. "Agreement" means first of all the sameness of interpretation (semantics) of words and expressions. The following are examples illustrating the difficulty of the task of achieving an agreement.

How to convey meaning when translating

First of all, you need to recall that the POSIX standard is set forth in English, which in nature provokes ambiguity (for example, the same word can be nouns, adjective and verb), and "semantic traps" listened almost on every page. A good illustration of the said is an example of fiction. One of the most famous works of Oscar Wilde, which brilliantly used this feature of the English language, - The Importance of Being Earnest - is known in Russian called "How important to be serious." However, the English name has a second meaning: Earnest (serious) - the surname of one of the characters, and the name could be translated differently: "How important to be Ernst". There is a Russian surname silver, and if there was a serious surname, the translation would be perfectly accurate, with the transfer of both meanings.

The same is the case with the name of the standard: Portable Operating System Interface. The adjective portable (mobile) refers to the operating system, and to the application program, but it is not possible to express it shortly in Russian, you can translate as a "mobile operating system interface" or "operating system interface that provides mobility of application programs." The second option better reflects the intentions of the standard developers, but at the same time the first washed was lost (the more familiar first option was preserved).

Semantics of the word "standard"

The main text of the standard is preammed by the preamble, in which the meaning of the word IEEE Standards2 is explained. As follows from these clarifications, there are at least three semantic differences from the Russian-speaking term GOST:

(1) Intuitively believes that GOST has the power of the law whose violation is persecuted; POSIX is a set of requirements, following which is the case exclusively voluntary.

(2) GOST acts up to cancellation (many, probably, had to hear the expression "GOST Nobody canceled"); In the preamble to POSIX, it is said that if the standard was not revised for 5 years, this means that questions considered in it most likely lost the relevance, and it can be considered canceled automatically;

(3) GOST ANONOMEN; In the introductory part of POSIX, a list of those persons who participated in the development of this standard are given, and also gives the address in which you can send interpretation requests; It is also said that the answer to each request is subject to the coordination procedure (in other words, the authors of the standard agree with each other before giving the answer).

Thus, the translation of even such a well-known word as Standard word "standard" requires comments.

The semantics of the words "must", "not specified", "not defined", "determined by the implementation"

Section 2 of the Standard is called "Terminology and General Requirements". It contains the definitions of not only special terms (such as "process" or "semaphor"), but also such, it would seem that self-evident words, as "must" or "may". Since POSIX.1 is a standard on the interface, its requirements are related to both the operating system and the application program. Explicit requirement is expressed by the word "must" (shall), for example: "In case of successful completion, the Link () function must return the zero value." In this example, we are talking about the requirement to the operating system: the Link () function must be implemented so that at a successful completion, the zero value returned.

The terms "not specified" and "not defined" express the same idea that the standard admits freedom of choice, but the meaning of these terms is varied. The term "not specified" implies that we are talking about some correct (actions, software structures, etc.), and the term "not defined" - about incorrect (erroneous). The informative part of the standard provides the following explanation.

The term "not specified" means that many options (outcomes, the results of the function call, etc.) is assumed to be known, and the standard allows any of them; In a specific implementation of the operating system, anyone can be selected, and such a system is considered to be the relevant standard. Applied program (strictly relevant standard) must be written in such a way that it worked correctly in any variant; Essentially, this term implicitly expressed a requirement for an application program.

Let us give an example: "READDIR () function must return a pointer to the structure relating to the next directory element. Whether the items of the directory are returned with the "dot" and "point - point" names, the standard is not specified. " In this example, four outcome is possible, and the requirement for an application program is that it must be designed for any of them.

Another example: "If the SigWait () function, which prescribes the waiting for the signal with the specified number is caused in several control streams, then when the signal is received, no more than one of them should return from Sigwait (). In what kind of control flow it will happen, the standard is not specified. " In this example, many possible outcomes may be more, but they are also known, and the requirement for an application program is that it should work correctly at any outcome.

The term "not defined" implies that even many outcomes are not known, any outcome is possible, even deplorable (for example, collapse of the system, data loss, etc.). Essentially, this term implicitly expressed the requirement for the application program not to use the appropriate data or designs. For example: "If the DIRP argument function readdir () does not refer to the currently open directory, the result is not defined."

This example contains a request to applied as an argument readdir () function only link to an open directory; Violation of this requirement can lead to disastrous consequences, and liability for it is assigned to an application programmer.

Here is another example: "In case of successful completion, the read () function must return an integer that indicates the number of virtually read bytes. Otherwise, the function must assign an error code to ErRNO and return -1, and the contents of the buffer to which the BUF argument specifies is not defined. "

Use in an application program from a buffer in case of an error of the read () function, the standard prohibits, and the consequences of the violation of this requirement imposes on the application programmer.

The meaning of the term "is determined by the implementation" differs from intuitive. Obviously, in a specific operating system, there can be no "non-council" or "uncertain" result, some particular result will be obtained. The term "determined by the implementation" expresses the requirement of the standard to the documentation for the operating system: the result not only should be clarified (the developer of the operating system will have to do anyway), but also explicitly reflects the documentation for the system.

Semantics defaults

No regulatory document can cover the entire variety of cases that may meet in practice, so it is inevitable about something silent3. For example, in the description of the function it can be said that its argument can take values \u200b\u200bfrom a certain range, but nothing says that it will be the result if the argument does not fall into this range. Obviously, in order to avoid misunderstandings, it is necessary to have a single default semantics. In the informative part of the standard there is a curious phrase: "The generally accepted semantics of the default is prohibited." This statement contradicts the well-known slogan of a decade ago "All that is clearly not prohibited is allowed. Apparently, he was so rooted in consciousness of citizens that many, even programmers, do not agree with the procitated statement of the standard. Meanwhile, if the use of any design is clearly not allowed and does not follow from the description, then any practitioner programmer realizes that its use is risky, and if it does not work, it does not occur to a claim.

Processes and control flows

Both of these terms express the idea of \u200b\u200bthe parallelism of execution. The UNIX operating system was originally conceived as a multiplayer, and programs that are launched by different users must be securely isolated from each other to accidentally distort "other people" data. This isolation is provided by the fact that the user program is executed within a certain process developing in its own virtual address space. Even if the program has global data, when it starts it in different processes, they will be automatically "divorced" by different address spaces.

However, the mechanism of processes is not quite satisfactory when programming real-time tasks. The real-time application program (acting on behalf of the same user) can often be naturally represented as parallel to the executable parts, which are called "control flows" (Thread). The most significant difference from processes is that all control flows are developing in a single address space; This ensures quick access to global data, but at the same time the risk of unintentional distortion of their distortion, and that this does not occur, it is necessary to comply with some discipline programming. The relevant recommendations are contained in the informative part of the standard.

It should be emphasized that the idea of \u200b\u200bmultithreading is implemented in many real-time operating systems, and is implemented differently in the sense that different sets of attributes and interface functions correspond to each control stream; Sometimes instead of the term "control flow" (Thread) uses the term "task" (Task). In order to avoid misunderstandings, the standard emphasizes that it comes exclusively about POSIX control streams, and the names of the corresponding interface functions have the PTHREAD_ prefix (for example, pthread_create (), pthread_join (), etc.).

Compliance with standard. The semantics of the word "corresponds"

It is intuitive that if two subjects are made in accordance with the same standard, then they are guaranteed to "match" with each other and will work together in a pair; It is in this that the purpose of the introduction of the standard for the conjugation (interface) is. Since POSIX is a standard on the interface, you can talk about compliance with the standard of both the operating system and application program.

POSIX.1 standard contains several hundred (if not thousands) requirements; It is considered self-evident that if at least one of them is not fulfilled, the system (or application program) does not satisfy the standard. At the same time, such a number of UNIX operating systems and application programs for them are written to date, which is unlikely to reasonably require full correspondence in the specified sense. The difficulties of developing an international standard of this kind are exacerbated by the existence of different national languages. Even if you forget about application programs designed to process texts in national languages, almost any application must issue some diagnostic messages and / or perceive the texts entered by the operator.

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

Secondly, many interface funds are declared optional (optional); The standard requires the optional interface functions to be either worked out as prescribed by the standard, or have always returned a special error code, Enosys (meaning that the function is not implemented). Optional means are divided into several groups, each of which corresponds to some configuration constant, which is declared (#Define operator) in the corresponding header file; This ensures the possibility of finding out whether the function is implemented on the compilation phase.

The described admission of mobility was invented not by the authors of POSIX, and long ago applied in practice; In many operating systems, configuration constants are applied to identify the system itself or its version. And here the standard does not offer anything fundamentally new, but only systematizes the existing practice.

Standardization objects and standard structure

To speak briefly, the objects of standardization POSIX.1 are names and semantics. More specifically, we are talking about the following.

Interface features. 357 functions are standardized, and 107 functions are taken from standard SI libraries (mathematical, row processing, input / output, etc.); These functions are considered part of the POSIX.1 standard, but their full description is contained in the standard programming language.
Names of system data types. These names have a suffix _t.
The names of the header files, as well as the minimum composition of these files.
Names of system-wide global variables (for example, ERRNO).
Symbolic names for error codes that can be installed when working out functions. These names begin with the letter E (EPERM, Enotempty, etc.).
Constant configuration names. These names have prefix _posix_.
Symbolic names of signals; These names have a SIG prefix. In addition to 20 "traditional" signals (SIGABRT, SIGALRM, etc.), real-time signals are standardized, the numbers of which should occupy some solid range from Sigrtmin to SigrtMax inclusive, containing no less RTSig_max numbers.
Symbolic names corresponding to the values \u200b\u200bof individual arguments of some functions (for example, the CMD argument function fcntl () can take F_DUPFD, F_GetFD, F_Getlk values, 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 is the regulatory part - contains the requirements and recommendations of the standard (18 sections), the second - informative part - contains applications that provide a list of references, comments and explanations to the regulatory part, the composition of the header files, an example of a profile ("projection") of the standard ( for Denmark), characteristics and methods of measuring the performance of the most important functions, as well as a description of additional interface functions to work with real-time files; It is expected that in the following editions of the Standard, these functions will be included in the regulatory part.

The idea of \u200b\u200bwhich types of services of the operating system are covered by the standard, gives the sum of the "summary of the Standard sections".

Conclusion

The main content of the POSIX standard is the semantics of interface functions. Standardization of semantics - the case itself is not easy (everyone knows how difficult it is to agree even to two people), and difficulties are exacerbated by a lot of people are currently involved in programming activities. For example, the parallel execution paradigm is expressed by such terms as the "process", "task" and "management flow", but from the point of view of practical programming "Task" in the IBM OS / 360 operating system and in the real-time operating system VXWORKS is not one and also. Another example is semaphores. Semaphores are binary, integer ("with a meter") and a mutual exception (which, by the way, programmers are called "mutexes", sphelially seeking to avoid misunderstandings). And integer semaphores, for example, in the VXWORKS operating system, is not at all the same as POSIX semaphores.

The authors of the POSIX standard, perfectly realizing how difficult it is to make people abandon their habits (which they call the "established practice"), declare that they made a logically connected and minimal system of interface functions covering most of the services traditionally provided by the operating system, in detail described the exact semantics of these functions and offer everyone to use them in their developments4.

When reading the standard sometimes the impression arises that some formulations had a single goal: not to withdraw some application programs or operating systems from the category. Such a goal was indeed set and clearly formulated in the introduction: the standard should take into account the current practice to maximize the extent. However, the main goal is to ensure the mobility of application programs.

About authentic

Sergey Romanyuk - senior Researcher of the Research Institute of System Research, Head of POSIX Standard Translations Group. You can contact him e-mail by the address: [Email Protected]

1 It should be added that the work on the standard continues for many years; New questions are identified, and they are either included in one of the existing parts, or are made in the form of a separate part, which can later be canceled. This happened, for example, with the interface means of real-time, which were first announced as POSIX.4, and subsequently included in POSIX.1.

2 IEEE is an organization in which the POSIX standard has been developed.

3 Here the "Mistor" means Silent, not Default; This is not about some implied values \u200b\u200bthat are actually declared, but about the declaration of mention at all.

4 The 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. Wereruve, A.L.Fridman. Mobile operating system. Directory. Moscow, Radio and Communication, 1991.

ISO / IEC 9899: 1990, Programming Languages \u200b\u200b- C.

Section 1	- Introduction
Section 2.	- Terminology and definitions
Section 3.	- Process Management Functions (Creating, Replacing Images, Completion) and Signals (Mask Management, Signal Response)
Section 4.	- Identification (processes, users, systems, terminal), a survey of times spent on the process execution, survey of environment variable.
Section 5.	- Manage files and catalogs
Section 6.	- Input and output functions
Section 7.	- Terminal Management Functions
Section 8.	- functions borrowed from the standard
Section 9.	- Access to user databases and user groups
Section 10.	- Data formats for archiving and exchange (tar and cpio)
Section 11.	- Synchronization tools: semaphores, mutexes and variable conditions
Section 12.	- Memory Management Functions: Fixing and Disagreement Process Address Space, Displays Memory Files, Memory Protection, Shared Memory
Section 13.	- Functions related to planning processes and control flows
Section 14.	- Manage clocks and timers
Section 15.	- Report queues management
Section 16.	- basic functions related to control flows
Section 17.	- Individual control stream data (Thread-Specific Data)
Section 18.	- means of destroying control flows

Standards

Sergey Zolotarev,

The purpose of this article is to attempt to make a certain clarity in the development history of the POSIX standard in relation to real-time operating systems (OS RV).

As an introduction: Why do you need a programming interface standardization?

One of the most important properties of the POSIX standard is that it defines a "standardized programming interface", which the developers of complex software and hardware systems should adhere to the developers. The creators of these systems are forced to face such requirements as a short time of entering the market (due to rigid competition), minimizing costs and accelerating investment returns. At the same time, the lion's share of expenses caused by the slowdown in the development process is related to the fact that programmers have to "invent a bicycle", again and again implementing functionality, which has long been available. But this could be avoided by:

Reuse code from past and parallel projects;

Transfer of code from other OS;

Attracting developers from other projects (including using other OS).

All this is possible due to the use of the OS with a standardized API. Moreover, if in the first case the organization is enough to have a certain internal standard (which is especially characteristic of branded OS), then the second two cases are just requiring the availability of generally accepted standards - for example, POSIX.

Thus, using a POSIX-compatible OS project as a platform, the developer gets the opportunity to transfer ready code At the level of source text, both from their past or parallel projects and from projects of third firms. This not only significantly reduces the timing of software development, but also improves its quality, since the proven code always contains less errors.

Who is who in the development of POSIX

And let's start with the very standard POSIX, but in ordering the role of organizations involved in working on it.

The first participant is IEEE. Institute Of Electrical and Electronics Engineers, Institute of Electrician Engineers and Electronics), Public Non-Profit Association of Professionals. IEEE leads its history since 1884 (formally - since 1963), combines 380,000 individual members from 150 countries, publishes the third part of the technical literature concerning the use of computers, management, electrical and information technologies, as well as more than 100 magazines, popular in the environment of professionals; In addition, the Association is per year over 300 major conferences. IEEE participated in the development of more than 900 existing standards (www.ieee.ru/ieeee.htm). Today, this institute is engaged in preparing, approval, approval, publishing standards, but in its formal status does not have the authority to accept such documents as international or national standards. Therefore, the term "standard" in the understanding of IEEE rather means "specification", which more corresponds to the status of the documents taken by the Association. In accordance with IEEE, participates in the programs of a number of international and regional organizations - IEC, ISO, ITU (European Telecommunications Standards Institute for Electrotechnical Standartization) and in national programs, such as the program of such an organization like ANSI.

IEEE includes PASC (Portable Application Standards Committee; www.pasc.org/) - Committee of Association, which is developing a POSIX family family. Earlier, Pascc was known as the Technical Committee on Operations.

The second work participant - ANSI (American National Standards Institute, American National Standards Institute; www.ansi.org) - a private non-profit organization that administers and coordinates in the United States on standardization issues. It employs only 75 people, but the members of ANSI are more than 1000 companies, organizations, government agencies and institutions. ANSI represents the United States in two main international organizations for standardization - ISO and IEC.

Third participant - ISO. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, INTERNATIONAL ORGANIZATION ON STANDARDATION; WWW.ISO.ORG). It was created in 1946 by decision to coordinate standards and the UN General Assembly and officially began work on February 23, 1947. ISO is a network of national standardization institutions from 146 countries (one country - one ISO member) with the Central Secretariat in Geneva ( Switzerland). ISO standards are developed in technical committees, the first result of which is a DRAFT International Standard document (DIS), turning after several matching in Final Draft International Standard (FDIS). After that, the question of approval of this document is made to a vote; With a positive result, it becomes an international standard.

Finally, - IEC. International Electrotechnical Commission, the International Electrotechnical Commission - IEC; www.iec.ch/), founded in 1906, IEC prepares and publishes international standards for all electrical, electronic and related technologies. As of November 1, 2004, the National Committees of 64 countries were the valid members of this commission. IEC also publishes recommendations that come out in English and French and carry out the status of international standards. They are based on regional and national standards. Technical committees (TC) are responsible for the preparation of standards in various areas of IEC activities, and national committees interested in the activities of a TC are also involved.

IEC. - Key organization in the preparation of international standards for information technology. This area has a Joint Technical Committee on Information Technology - JTC 1 formed in 1987 in accordance with the Agreement between IEC and ISO. JTC1 has 17 subcommittees who supervise all the development - from software to programming languages, computer graphics and editing images, interconnections of equipment and security methods.

Preparation of new IEC standards includes several stages (preliminary, stage of supply, preparatory, stage of the technical committee, stage of request, approval, publication). If it is planned that the IEC document will be only a technical specification, and not an international standard, the revised version of the document is sent to the central office for publication. For the development of the final project of the International Standard (FDIS), four months are given. If all members of the technical committee are approved, it goes to the central office for publishing without the FDIS approval stage. After that, FDIS falls into national committees to approve it within two months. FDIS is considered approved if more than two thirds of national committees voted for him, and the number of negative votes does not exceed 25%. If the document is not approved, it is sent to revise technical committees and subcommittees. The standard must be published no later than two months after the approval of FDIS.

A few more organizations are related to the development and adoption of POSIX standards.

Open Group. - International Organization for Software Standardization, which combines nearly 200 manufacturers and user communities working in the field of information technology (www.opengroup.org/) .opengroup was created in 1995 by merging the two predecessors: X / Open and Open Software Foundation (OSF). Open Group specializes in the development of software certification methodologies and testing for compliance with certain requirements. In particular, Open Group is certified for areas such 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 Family of POSIX standards (www.opengroup.org/certification/).

AustinCommonstandardsRevisionGroup (CSRG) - The United Technical Working Group formed in 2002 ISO, IEC and Open Group to create and maintain the latest versions of the standard 1003.1, which will be formed based on ISO / IEC 9945-1-1996, ISE / 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) - Federal Agency complied with Commerce Department's Technology Administration (www.nist.gov/public_affairs/general2.htm), founded in the United States in 1901. NIST's task is the development and propaganda of standards and technologies in order to improve product quality. The NIST includes information technology laboratory. INFORMATION TECHNOLOGY LABORATORY - ITL)One of the results of which are federal information processing standards (Federal Information Processing Standards - FIPS, www.opengroup.org/testing/fips/general_info.html).nist/itl offered in 1991 the initial set of tests for POSIX certification in 1991 Within FIPS PUB 151-1 1990.

What is POSIX?

Formally term Posix. proposed by Richard Stallman (Richard Stallman) as an abbreviation for P.ortable. O.perating S.ySTEM INTERFACE FOR UN IX (Portable interface of operating systems for UNIX). POSIX was developed for UNIX-like operating systems (their first versions are counting from the beginning of the 1970s) in order to ensure the portability of applications at the source code 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, turning into POSIX, and already in the next publication (back in 1986) this new version was used. For some time under POSIX, the reference (or synonym) was understood as a group of IEEE 1003.1-1988 related documents and part of ISO / IEC 9945, and as a complete and approved international ISO / IEC standard 9945.1: 1990 POSIX was adopted in 1990. POSIX specifications define standard The mechanism of interaction between the application program and the OS and currently include more than 30 standards under the auspices of IEEE, ISO, IEC and ANSI.

Throughout its history, POSIX has passed a big way, while many times changed the designations of specifications, their specific content, procedures and logistics of their verification. Over the past time, several editions of the POSIX standard were issued in various international organizations.

POSIX Standard Development History

The first version of the IEEE STD 1003.1 specification was published in 1988. Subsequently, numerous editions of IEEE STD 1003.1 were adopted as international standards. POSIX development stages:

- 1990 The editorial office released in 1988 was redesigned and became the basis for further editions and additions. It was approved as an international standard ISO / IEC 9945-1: 1990.

- 1993 The editorial office of 1003.1b-1993 comes.

- 1996 IEEE STD 1003.1B-1993, IEEE STD 1003.1C-1995 and 1003.1i-1995 were made, but the main part of the document remained unchanged. In 1996, the edition of IEEE STD 1003.1 was also approved as an international standard ISO / IEC 9945-1: 1996.

- 1998 There is a first standard for "real-time" - IEEE STD 1003.13-1998. This is the expansion of the POSIX standard for embedded real-time applications.

- 1999 It was decided to make significant changes in the main text of the standard for the last 10 years, including unification with the standard 1003.2 (Shell and utilities), since by that moment these were separate standards. PASC decided to finish changing the basic text after the completion of the standards of IEEE 1003.1A, 1003.1D, 1003.1G, 1003.1J, 1003.1q and 1003.2b.

- 2004 Latest today, the editorial board of 1003.1 was published on April 30 and was released under the auspices of Austin Common Standards Revision Group. It made changes regarding the editorial board of 2001. Formally, the editorial office of 2004 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 standards of POSIX for RV OS

For real-time operating systems, seven standard specifications are most important, but only three were widely supported in the commercial OS:

1003.1A (OS Definition) defines the basic interfaces of the OS, job management, signals, functions file System and work with devices, user groups, conveyors, fifo buffers;

1003.1B (Realtime Extensions) describes real-time extensions, such as real-time signaling, priority dispatching, timers, synchronous and asynchronous input, semaphores, shared memory, messages. Initially (until 1993), this standard was indicated as POSIX.4;

1003.1C (Threads) Defines stream support functions (threads) - flow control, stream attributes, mutex, dispatching. Originally designated as POSIX.4a.

In addition to these standards, the following standards are important for the RV, which were implemented as part of the STD project 1003.1-2001:

IEEE 1003.1D-1999. Additional expansions of real time. Initially designated as POSIX.4B;

IEEE 1003.1J-2000. Improved (Advanced) real-time expansion;

IEEE 1003.1q-2000. Tracing.

Certification procedure

To meet the POSIX standard, the operating system must be certified according to the results of the corresponding test set. Since the appearance of POSIX, the test set has undergone formal and actual changes.

In 1991, NIST has developed a POSIX test program within FIPS 151-1 (http://standards.ieee.org/regauth/posix/posix-a.fm5.pdf). This testing option was based on IEEE 1003.3 "Standard for Test Methods for Measuring Conformance to Posix" Draft 10, May 3, 1989. In 1993, NIST graduated from the testing program for FIPS 151-1 and began a 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)," ISO / IEC 9945-1: 1990 standard. Test sets for FIPS 151-2 were based on IEEE 2003.1-1992 "Standard for Test Methods for Measuring Conformance to Posix".

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

In 1997, Nist / ITL announced its intention to terminate the certification for FIPS 151-2 at the end of the current year (officially - December 31, 1997), at the same time Open Group announced that it was going to take on October 1 The year of certification service in accordance with FIPS 151-2, based on the NIST / ITL program. The same functions from January 1, 1998 assumed the IEEE Standardization Association (IEEE-SA), and also based on FIPS 151-2.

In 2003, IEEE-SA and Open Group announced the beginning of a new joint program for the certification of recent POSIX versions, starting with IEEE 1003.1 (TM) 2001. Now Open Group has several tests 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). The product is considered to be certified by POSIX if it passed the full certification procedure, according to test results, it satisfies all presented requirements and is listed in the official register of certified products.

Test sets 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 (multipurpose real time);

VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - a set of conformance tests for IEEE STD system interfaces 1003.1-2003 (mandatory parts only);

VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscppcts2003.htm) - a set of conformance tests for IEEE STD 1003.1-2003 (Shell and Utilities - only mandatory parts).

In addition, Open Group has developed tests for POSIX Realtime standards and Embedded Posix standards profile. A set of tests for POSIX REALTIME (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 REALTIM 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;

Embedded Posix Standards Profile Tests Set (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 test);

IEEE POSIX 1003.13-1998 PROFILE 52.

A little about confusion in terminology

In relation to the group of standards POSIX in English, not one, but as many as three terms. Unfortunately, they are similar in value and are often translated equally, which brings a certain confusion. Terms these are:

Compatibility (literally "compatibility");

Compliance (literally "compliance");

Sonformance (literally "consistency").

The first term applied to POSIX is not formally defined. The second means that the organization is a software producer independently declares that this product (fully or partially) meets the following Nist-PCTS standards. The third term implies that the software has passed installed system Tests either using an accredited laboratory or within the Open Group and this has a documentary confirmation (the so-called Conformance Statement). Further in the text of the article everywhere there will be originals of terms to exclude ambiguity.

Certified OS RV.

If you adhere to strict rules requiring that the data on the certified OS RV be published in the official register and testing were conducted by level conformance.You currently have only two certified OS RV (data is given in chronological order):

- Lynxos v.3. (Product of the company Lynx Real-Time Systems, which is now called Lynuxworks, Inc., www.lynuxworks.com) is intended for development on built-in systems operating in hard real-time manufacturers, manufacturers of complete and telecommunications equipment, in particular manufacturers of onboard systems of military use . Development can be carried out both on the target system (self-hosted) and on the tool computer (HOST), ready to designed to work on the target system (target). LynxOS v.3 is certified for consistency (Conformance)pOSIX standard on the Intel and PowerPC platform. Information about this can be found on the IEEE website http://standards.ieeee.org/regauth/posix/posix2.html.lynxos certified by POSIX 1003.1-1996 Mindcraft, which is the IEEE POSIX Accredited Posix Testing Laboratory for NIST FIPS 151 tests 2 Conformance Test Suite. Document number confirming certification: Reference File: IP-2LYX002, REFERENCE FILE: IP-2LYX001.

- INTEGRITY V.5 (The product of the company Green Hills Software, www.ghs.com) is certified for consistency (Conformance) By POSIX 1003.1-2003, System Interfaces for PowerPC architecture in July 2004 (http://get.posixcertified.ieee.org/select_product.tpl). Set of tests VSX-PCTS 2003.

POSIX and QNX operating system

QNX V.4.20(Developer - Firm QNX Software Systems, www.qnx.com) certified for compliance (COMPLIANCE) POSIX 1003.1-1988 for the platform Intel Company DataFocus Incorporated. Testing was conducted on September 13, 1993, the date of issuance of the document - November 1, 1993. Set of tests NIST PCTS 151-1, version 1.1.

QNX Neutrino (version 6.3) Complies (complies to) Next standards of the 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 certify (conformance) QNX Neutrino according to some of these standards; Works are scheduled 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. PROGRAMING 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.

Software) - the task of exceptional importance and complexity; Nowadays, this circumstance hardly needs extensive justifications. One of the generally accepted ways to enhance the mobility of software is standardizing the environment of applications: programming interfaces provided, utilities, etc. At the level system Services A similar environment describes the POSIX standard (Portable Operating System Interface - mobile operating system interface); The name is proposed by a well-known specialist, the founder of the Free Software Foundation Richard Tornen.

We will consider the most modern of the available versions of the POSIX standard, as amended by 2003, which can be called "Standard Triple", namely: IEEE STD 1003.1 standard, Technical standard Open Group and (see [6]), which is most important for us, the international standard ISO / IEC 9945 (see [1], [2], [3], [4]).

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

The fundamental document for the revised standard, the first project of which was presented in July 1999, were the basic specifications from the Open Group, since they included the provisions of IEEE and ISO / IEC standards. In 2001, upon completion of the preparatory work, the standard contained the following four parts:

main definitions (terms, concepts and interfaces common to all parts);
description application C-Interface to system services;
description of the interface to system services at the level command language and service Programs ;
a detailed explanation of the standard provisions, the rationale for the decisions taken.

Further in ISO, IEEE and Open Group with a greater or lesser speed (in 2001-2002), a formal approval of the new POSIX standard has passed. In the meantime, relatively minor corrections were accumulated, taken into account in the 2003th year.

With the development of the standard, the interpretation of the term "POSIX" was expanding. Initially, he referred to IEEE STD 1003.1-1988, described application program interface OS class UNIX. After standardizing the interface at the command language level and service programs, it is more correctly understood under the word "POSIX" standard in general, denoting the part 2 and 3 listed above via POSIX .1 and POSIX .2 in accordance with the numbering of IEEE and ISO / IEC documents.

The main ideas of the POSIX standard

The POSIX standard describes a plurality of basic, system services required for the functioning of applications. Access to them is provided by an interface specified for the C, command language and common service programs.

Each interface has two sides: causing and called. The POSIX standard is primarily oriented to the calling. His goal is to make applications mobile at the source language level. This means, in particular, that when transferring c-programs to another operating platform, recompilation will be required. About the mobility of executable programs and / or object files does not matter.

POSIX standard is not limited to the UNIX environment framework. There are operating systems (OS) "independent origin" (for example, real Time Systems), providing the necessary services and thereby supporting the execution of POSIX -Ancable applications. It can be argued that following the POSIX standard facilitates the transfer of applications to almost any common operating platform. Additional efforts to improve mobility attached during the development phase will definitely pay off.

Determining the interface to system services, POSIX leaves the framework of their implementation. In particular, do not distinguish system calls and library functions. Are not an object of standardization means administration, hardware limitations and functions necessary only super successorwhat once again emphasizes the focus of the standard

Today we will try to find out what the POSIX standard describes. Standards are intended to ensure that my computer can interact with yours. Thanks to them, on two similar webpage computers or broadcast video in real time will look equally.

However, the standard are intended for larger tasks than a simple exchange of any data between users. Some standards define a special model, thanks to which features that are significantly superior in their value compatibility of files or networks. The POSIX standard refers to their number.

What is POSIX?

POSIX (pronounced "Posiks") is a portable operating system interface. But what does it mean? First, you need to designate the area of \u200b\u200bthe concept of "portability", in this concrete caseand decide on the concept of "interface". To find out this, it is necessary to repel from the fact that both concepts are inextricably linked.

"Portability", in the context of the POSIX standard, refers to source code (Not to the binary who are collected from these very sources). Now find out what "interface" is. In programming, the "interface" is the interaction of your code with the rest of the code. The interface is waiting for the provision of specific information from your code. Your code, in turn, involves obtaining certain information from the interface. Good example - FOPEN () function in SI. It expects information from 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 "File Descriptor". The file handle can be used to read the file or write to the file. This is the interface. From all this it follows that a POSIX-compatible code can be compiled under any POSIX-compatible operating system without major changes, which means it will be portable.

The list of interfaces relating to the POSIX standard is, however, even despite its huge length, it is possible that he is deficient. POSIX is not limited to system challenges, it also defines standards for shells of operating systems (shelves, otherwise - interfaces command line), system utilities, such as "AWK" or "ECHO", system libraries and many other things.

The POSIX standard appeared in the form of a project of Richard Pokalman in 1985 and was further decorated as IEEE STD 1003.-1998. As can be seen from the name, 1998 was the year of official publication. Since then, a large number of additions and extensions for POSIX have been released, which gradually turns into a whole family of standards, formally known as IEEE 1003, recognized as an international, with the designation of SO / IEC 9945, simply called the POSIX family standard.

The operating system is not at all necessary to be POSIX-compatible or even more so having a POSIX certificate, however it allows developers to create applications, tools and platforms, without rewriting code once by time, but only complement and connect to ready-to-finish. It is also not necessary to write a POSIX-compatible code at all, but this significantly improves the portability of projects between operating systems. This means that the ability to write a code that is compatible with the POSIX standard is valuable in itself, and certainly very useful for a career. Large projects, such as GNOME or KDE, adhere to the POSIX standard, which guarantees their work on different operating systems. POSIX subsystem is implemented even in recent issues Windows. Linux, as you know, supports most of the system calls related to the POSIX standard, as well as large extension to it, called the "standard Linux base", which is designed to combine Linux distributions in terms of supporting source code and binary data.

I hope we shed the light to the question "What is Posix." Have interesting information on the topic? Please share it in the comments.

POSIX and OS RV: attempt to systematization

Sergey Zolotarev, Nikolai Gorbunov

The purpose of this article is to attempt to make a certain clarity in the development history of the POSIX standard in relation to real-time operating systems (OS RV).

As an introduction: Why do you need a programming interface standardization?

reuse code from past and parallel projects;
transfer of code from other OS;
attracting developers from other projects (including using other OS).

Thus, using a POSIX-compatible OS as a platform for its projects, the developer is able to transfer the finished code at the source code level as from its past or parallel projects and from third-party projects. This not only significantly reduces the timing of software development, but also improves its quality, since the proven code always contains less errors.

Who is who in the development of POSIX

And let's start with the very standard POSIX, but in ordering the role of organizations involved in working on it.

The first participant is IEEE. Institute Of Electrical and Electronics Engineers, Institute of Electrician Engineers and Electronics), Public Non-Profit Association of Professionals. IEEE leads its history since 1884 (formally - since 1963), combines 380,000 individual members from 150 countries, publishes the third part of the technical literature concerning the use of computers, management, electrical and information technologies, as well as more than 100 magazines, popular in the environment of professionals; In addition, the Association is per year over 300 major conferences. IEEE participated in the development of more than 900 existing standards (www.ieee.ru/ieeee.htm). Today, this institute is engaged in preparing, approval, approval, publishing standards, but in its formal status does not have the authority to accept such documents as international or national standards. Therefore, the term "standard" in the understanding of IEEE should rather be understood as "specification", which is more responsible for the status of the documents taken by the Association. In accordance with IEEE, participates in the programs of a number of international and regional organizations - IEC, ISO, ITU (European Telecommunications Standards Institute for Electrotechnical Standartization) and in national programs, such as the program of such an organization like ANSI.

IEEE includes PASC (Portable Application Standards Committee) - Committee of Association, which is developing a family of standards POSIX (www.pasc.org/). Earlier, Pascc was known as the Technical Committee on Operations.

The second participant of work - Ansi. (American National Standards Institute, American National Standards Institute) - a private non-profit organization that administers and coordinates in the United States on standardization issues. It employs only 75 people, but members of ANSI are more than 1,000 companies, organizations, government agencies and institutions (www.ansi.org). ANSI represents the United States in two main international organizations for standardization - 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 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 institutions from 146 countries (one country is one ISO member) with the Central Secretariat in Geneva (Switzerland). ISO standards are developed in technical committees, the first result of which is a DRAFT International Standard document (DIS), turning after several matching in Final Draft International Standard (FDIS). After that, the question of approval of this document is made to a vote; With a positive result, it becomes an international standard.

Finally, - IEC. INTERNATIONAL ELECTROTECHNICAL COMMISION, INTERNATIONAL ELECTROCHNICAL 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, the National Committees of 64 countries were the valid members of this commission. IEC also publishes recommendations that come out in English and French and carry out the status of international standards. They are based on regional and national standards. Technical committees (TC) are responsible for the preparation of standards in various areas of IEC activities, and national committees interested in the activities of a TC are also involved.

IEC is a key organization in the preparation of international standards for information technology. This area has a Joint Technical Committee on Information Technology - JTC 1 formed in 1987 in accordance with the Agreement between IEC and ISO. JTC1 has 17 subcommittees who supervise all the development - from software to programming languages, computer graphics and editing images, interconnections of equipment and security methods.

A few more organizations are related to the development and adoption of POSIX standards.

Open Group. - International Organization for Software Standardization, which brings together almost 200 manufacturers and user communities working in the field of information technology (www.opengroup.org/). Open Group was created in 1995 by merging the two predecessors: X / OPEN and Open Software Foundation (OSF). Open Group specializes in the development of software certification methodologies and testing for compliance with certain requirements. In particular, Open Group is certified for areas such 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 Family of POSIX standards (www.opengroup.org/certification/).

Austin Common Standards Revision Group (CSRG) - The United Technical Working Group formed in 2002 ISO, IEC and Open Group to create and maintain the latest versions of the standard 1003.1, which will be formed based on ISO / IEC 9945-1-1996, ISE / 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) - Federal Agency complied with Commerce Department's Technology Administration (www.nist.gov/public_affairs/general2.htm), founded in the United States in 1901. NIST's task is the development and propaganda of standards and technologies in order to improve product quality. NIST includes an information technology laboratory (ITL), one of the results of activities that are federal information processing standards (Federal Information Processing Standards - FIPS, www.opengroup.org/testing/fips/general_info.html). Nist / ITL offered in 1991 the initial set of tests for POSIX certification under FIPS PUB 151-1 1990.

What is POSIX?

Formally term Posix. proposed by Richard Stallman (Richard Stallman) as an abbreviation for P.ortable. O.perating S.ySTEM INTERFACE FOR UN IX (Portable interface of operating systems for UNIX). POSIX was developed for UNIX-like operating systems (their first versions are counting from the beginning of the 1970s) in order to ensure the portability of applications at the source code level.

The initial description of the interface was published in 1986, then he was called IEEE-IX (IEEE "S Version of UNIX). However, the name has changed quickly, turning into POSIX, and this new version has been used in the following publication (back in 1986) . For some time under POSIX, reference (or synonym) was understood as a group of IEEE 1003.1-1988 related documents and part of ISE / IEC 9945, and as a complete and approved international ISO / IEC standard 9945.1: 1990 POSIX was adopted in 1990. POSIX specifications define The standard mechanism for interaction between the application program and the OS and currently include more than 30 standards under the auspices of IEEE, ISO, IEC and ANSI.

POSIX Standard Development History

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

POSIX development stages:

1990

The editorial office issued in 1988 was recycled and became the basis for further editors and additions. It was approved as an international standard ISO / IEC 9945-1: 1990.

1993

The editorial office of 1003.1b-1993 comes.

1996

IEEE STD 1003.1B-1993, IEEE STD 1003.1C-1995 and 1003.1i-1995 were made, but the main part of the document remained unchanged. In 1996, the edition of IEEE STD 1003.1 was also approved as an international standard ISO / IEC 9945-1: 1996.

1998

There is a first standard for "real-time" - IEEE STD 1003.13-1998. This is the expansion of the POSIX standard for embedded real-time applications.

1999

It was decided to make significant changes in the main text of the standard for the last 10 years, including union with the standard 1003.2 (Shell and utilities), since by the time it was separate standards. PASC decided to finish changing the basic text after the completion of the standards of IEEE 1003.1A, 1003.1D, 1003.1G, 1003.1J, 1003.1q and 1003.2b.

2004

Latest today, the editorial board of 1003.1 was published on April 30 and was released under the auspices of Austin Common Standards Revision Group. It made changes regarding the editorial board of 2001. Formally, the editorial office of 2004 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 standards of POSIX for RV OS

For real-time operating systems, seven standard specifications are most important (1003.1A, 1003.1J, 1003.1C, 1003.1D, 1003.1J, 1003.21), but only three were widely supported in the commercial OS:

1003.1A (OS Definition) Specifies the basic interfaces of the OS, job management, signals, file system functions and devices, user groups, conveyors, FIFO buffers;
1003.1B (Realtime Extensions) Describes real-time extensions, such as real-time signaling, priority dispatcher, timers, synchronous and asynchronous input, semaphores, shared memory, messages. Initially (until 1993), this standard was designated as POSIX.4.
1003.1C (Threads) Defines stream support functions (threads) - flow control, stream attributes, mutexes, dispatching. Originally designated as POSIX.4a.

In addition to these standards, the following standards are important for the RV, which were implemented as part of the STD project 1003.1-2001:

IEEE 1003.1D-1999. Additional expansions of real time. Initially designated as POSIX.4B;
IEEE 1003.1J-2000. Improved (Advanced) real-time expansion;
IEEE 1003.1q-2000. Tracing.

Certification procedure

In 1991, NIST has developed a POSIX test program within FIPS 151-1 (http://standards.ieee.org/regauth/posix/posix-a.fm5.pdf). This testing option was based on IEEE 1003.3 "Standard for Test Methods for Measuring Conformance to Posix" Draft 10, May 3, 1989. In 1993, NIST graduated from the testing program for FIPS 151-1 and began a 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)," The ISO / IEC 9945-1: 1990 standard. Test sets 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 Open Group announced the beginning of a new joint program for the certification of last versions of POSIX, starting with IEEE 1003.1 ™ 2001. Now the Open Group has several tests 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). The product is considered to be certified by POSIX if it passed the full certification procedure, according to test results, it satisfies all presented requirements and is listed in the official register of certified products.

Test sets 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 (multipurpose real time);
VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - a set of conformance tests for IEEE STD system interfaces 1003.1-2003 (mandatory parts only);
VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscppcts2003.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 REALTIM 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;

Embedded Posix Standards Profile Tests Set (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 test);
IEEE POSIX 1003.13-1998 PROFILE 52.

A little about confusion in terminology

compatibility (literally "compatibility");
compliance (literally "compliance");
sonformance (literally "consistency").

The first term applied to POSIX is not formally defined. The second means that the organization is a software producer independently declares that this product (fully or partially) meets the following Nist-PCTS standards. The third term implies that the software product has passed the set test system or using an accredited laboratory or within the Open Group and this has a documentary confirmation (the so-called Conformance Statement). Further in the text of the article everywhere there will be originals of terms to exclude ambiguity.

Certified OS RV.

If you adhere to strict rules requiring that the data on certified OS RV be published in the official register and testing were conducted in terms of conformance, now there are only two certified OS RV (data is given in chronological order):

Lynxos v.3. (Product of the company Lynx Real-Time Systems, which is now called Lynuxworks, Inc., www.lynuxworks.com) is intended for development on built-in systems operating in hard real-time manufacturers, manufacturers of complete and telecommunications equipment, in particular manufacturers of onboard systems of military use . Development can be carried out both on the target system (self-hosted) and on the tool computer (HOST), ready to designed to work on the target system (target). Lynxos v.3 is certified by consistency (Conformance) POSIX standard on the Intel and PowerPC platform. This information can be found on the IEEE website http://standards.ieeee.org/regauth/posix/posix2.html. LynxOS is certified by POSIX 1003.1-1996 by Mindcraft, which is the IEEE POSIX Accredited Posix Testing Laboratory for the NIST FIPS 151-2 Conformance Test Suite test. Document number confirming certification: Reference File: IP-2LYX002, REFERENCE FILE: IP-2LYX001.

INTEGRITY V.5 (The product of the company Green Hills Software, www.ghs.com) is certified for consistency (conformance) by POSIX 1003.1-2003, System Interfaces for PowerPC architecture in July 2004 (http://get.posixcertified.ieee.org/select_product. TPL). Set of tests VSX-PCTS 2003.

POSIX and QNX operating system

QNX V.4.20 (Developer - firm QNX Software Systems, www.qnx.com) Certified for compliance (compliance) by POSIX 1003.1-1988 for the Intel platform by DataFocus Incorporated. Testing was conducted on September 13, 1993, the date of issuance of the document - November 1, 1993. Set of tests NIST PCTS 151-1, version 1.1.

QNX Neutrino (version 6.3) Complies (complies to) Next standards of the 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).

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. PROGRAMING 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.

UNIX Standardization of operating systems and POSIX. Standards of real-time operating systems

About standards in general

Appointment and "Superbate" of the standard POSIX

About semantics

Compliance with standard. The semantics of the word "corresponds"

Standardization objects and standard structure

Conclusion

About authentic

Literature

The main ideas of the POSIX standard

What is POSIX?

POSIX and OS RV: attempt to systematization

As an introduction: Why do you need a programming interface standardization?

Who is who in the development of POSIX

What is POSIX?

POSIX Standard Development History

The most important standards of POSIX for RV OS

Certification procedure

A little about confusion in terminology

Certified OS RV.

POSIX and QNX operating system

Password recovery