Home > Computer > Basic concepts and ideas of the POSIX standard. Basic concepts and ideas of the POSIX standard POSIX and the QNX operating system

Basic concepts and ideas of the POSIX standard. Basic concepts and ideas of the POSIX standard POSIX and the QNX operating system

Subject: Operating systems.
Question: No. 8

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

OS design principles:

1.) The principle of modularity– under the module in general case understand 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 constantly present 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 program modules are loaded into RAM only when necessary and, if there is no 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. The result of generation is full version OS. 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 an OS to run programs written for other OSs or for earlier versions of a given OS, as well as for another hardware platform. It is necessary to separate questions binary compatibility And source compatibility applications.

Binary compatibility is achieved when you can take an executable program and run it on another OS. This requires compatibility at the processor instruction level, and compatibility at the system call level, 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 library and system call levels. 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, a program for a PC such as an IBM PC should preferably be executed 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 processor (or PowerPC) must execute binary code designed for an 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 to ensure compatibility of program 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: Open operating system available for analysis by both users and system specialists servicing 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 the language high level, preferably standardized, for example in the C language. A program written in assembly language is not generally 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 toolkits. In addition, according to POSIX, security tasks, real-time tasks, administration processes, network functions and transaction processing. 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 the system in detail virtual memory VMS (Virtual Memory System), MPE (Multi-Process Executing) multitasking and CTOS (An Operating System produced Convergent Technology...) technology for transferring operating systems. 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 In the MS Windows NT operating system, a special POSIX API support module has been introduced, which operates at the privilege level of user processes.

This module provides conversion and transmission of calls from a user program to the system kernel and back, working with the kernel through 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...

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

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

The history of the creation of this version is as follows. At the beginning of 1998, representatives of three organizations - the Standards Committee mobile applications Institute of Electrical and Electronics Engineers, Open Group and International Organization for Standardization Joint Technical Committee Subcommittee 22 Subcommittee 22 Working Group 15 (JTC1/SC22/WG15) have begun consultations on the merger and development of the system services interface standards they oversee: IEEE Std 1003.1, IEEE Std 1003.2, Open Group Core Specifications, ISO/IEC 9945-1, ISO/IEC 9945-2. In September of the same year, an organizational meeting of the group formed to achieve this goal was held in Austin, Texas, at the office of IBM Corporation (see http://www.opengroup.org/austin).

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

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

Further, the ISO, IEEE and Open Group, with greater or lesser speed (in 2001-2002), formally approved the new POSIX standard. Meanwhile, relatively minor corrections accumulated and were taken into account in the 2003 edition.

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

Basic ideas of the POSIX standard

The POSIX standard describes many basic, system services necessary for the functioning of application programs. They are accessed through an interface specified for the C language, a command language, and common utility programs.

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

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

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

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 their projects, the developer has the opportunity to transfer ready-made code at the source text 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 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 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 question of approval of this document put to 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 fields of activity of the IEC, 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, interconnection of equipment and security methods.

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

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

Open Group is an international software standards organization that brings together almost 200 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)- united 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 system interface for Unix). POSIX was developed for UNIX-like operating systems (their first versions date back to the early 1970s) with the goal of ensuring application portability at the source level.

The initial description of the interface was published in 1986, then it was called IEEE-IX (IEEE’s version of UNIX). However, the name quickly changed 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 interaction mechanism application program and OS and currently includes more than 30 standards under the umbrella of IEEE, ISO, IEC and ANSI.

POSIX has come a long way throughout its history, with numerous changes to the designation of 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, the seven standard specifications are most important, but broad support in commercial operating systems we received only three:

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 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 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 in English Often not one, but three terms are used. 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 software product 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 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

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.

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). 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. The title was added: "Part 1: System Application Program Interface (API)" ("Part 1: System Application Program Interface (API) [C Language]"), which meant that the standard described the program 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 the APIs of these tools.

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

Planned release in the future new version IEEE 1003.1, which includes 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.

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 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 fields of activity of the IEC, 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.

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/). The Open Group was created in 1995 by merging its two predecessors: X/Open and the Open Software Foundation (OSF). Open Group specializes in developing software certification methodologies and testing for compliance with specific requirements. In particular, the Open Group is engaged in certification for such areas as COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) and, finally, POSIX family of standards (www.opengroup.org/certification/).

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

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

What is POSIX?

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

The initial description of the interface was published in 1986, then it was called IEEE-IX (IEEE's version of UNIX). However, the name quickly changed, becoming POSIX, and already in the next publication (back in 1986) this new 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. This standard was originally (until 1993) designated POSIX.4.
1003.1c (Threads) defines functions for supporting threads (threads) - thread management, thread attributes, mutexes, dispatching. Originally designated POSIX.4a.

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

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

Certification procedure

In 1991, NIST developed the POSIX testing program under 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 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 of that year. same year, certification service in accordance with FIPS 151-2, based on the NIST/ITL program. The same functions were taken over by the IEEE Standards Association (IEEE-SA) on January 1, 1998, also based on FIPS 151-2.

In 2003, IEEE-SA and the Open Group announced the start of a new joint program to certify the latest versions of POSIX, starting with IEEE 1003.1™ 2001. The Open Group now has several test suites that cover IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 ,IEEE Std 1003.1-2003 and IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). A product is considered POSIX certified if it has passed 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).

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

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

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

A little about confusion in terminology

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

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

The first term, as applied to POSIX, is not formally defined. The second means that the organization that produces the software product independently declares that this product (fully or partially) complies with the listed NIST-PCTS standards. The third term implies that 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.

15.11.2020

Computer

The most interesting:

Label each polygon and measure the lengths of the sides of each

Connecting YouTube to TV

Names of large numbers Solving a compound problem