POSIX and RT OS: an attempt at systematization

Sergey Zolotarev, Nikolay Gorbunov

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

As an introduction: why is software interface standardization necessary?

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

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

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

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

Who's Who in POSIX Development

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

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

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

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

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

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

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

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

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

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

What is POSIX?

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

The initial description of the interface was published in 1986, then it was called IEEE-IX (IEEE's version of UNIX). However, the name quickly changed, becoming POSIX, and already in the next publication (back in 1986) this new 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.

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

History of the development of the POSIX standard

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

POSIX development stages:

1990

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

1993

Revision 1003.1b-1993 is released.

1996

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

1998

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

1999

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

2004

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

The most important POSIX standards for RT OS

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

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

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

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

Certification procedure

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

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

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

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

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

Test suites include:

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

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

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

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

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

A little about confusion in terminology

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

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

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

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

POSIX (Portable Operating System Interface for Computer Environments) is an IEEE (Institute of Electrical and Electronics Engineers) standard that describes system interfaces.

"In this context, system commands should be understood as a certain set of programs that allow you to control computing processes, for example pstat, kill, dir, etc.

POSIX interface__________________________________________________________ 305

faces for open operating systems, including shells, utilities and tools. In addition, according to POSIX, security tasks, real-time tasks, administrative processes, network functions and transaction processing are standardized. The standard is based on UNIX systems, but can also be implemented in other operating systems.

The POSIX interface began as an attempt by the IEEE to promote application portability in UNIX environments by developing an abstract, platform-independent standard. However, POSIX is not limited to UNIX systems; There are various implementations of this standard in systems that meet the requirements of IEEE Standard 1003.1-1990 (POSIX.1). For example, the well-known QNX real-time OS complies with the specifications of this standard, which makes it easier to port applications to this system, but it is not a UNIX system in any form, because its architecture uses completely different principles.

This standard details the Virtual Memory System (VMS), Multiprocess Executing (MPE), and Portable Operating System (CTOS) technology. So POSIX is actually many POSIX standards. 1-POSIX. 12. In table. 9.1 lists the main areas described by these standards. It should also be particularly noted that in POSIX. 1 The main language for describing system API functions is assumed to be C.

Table 9.1. POSIX family of standards

Standard ISO Standard Brief Description

POSIX.0 No Introduction to the open systems standard. This document

is not a standard in its pure form, but represents recommendations and a brief overview of technologies

POSIX.1 Yes System API (C language)

POSIX.2 No Shells and utilities (IEEE approved)

POSIX.3 No Testing and verification

POSIX.4 No Real-time tasks and threads of execution

POSIX.5 Yes Use of ADA language applicable

to the POSIX standard. 1

POSIX.6 No System security

POSIX.7 No System administration

POSIX.8 No Network, transparent file access, abstract

network interfaces independent of physical protocols, RPC calls, system communication with protocol-dependent applications

POSIX.9 Yes Use of Fortran language, applicable

to the POSIX standard. 1

POSIX. 10 No Super-computing Application Environment Profile (AEP)

POSIX. 11 No AEP Transaction Processing

POSIX. 12 No Graphical user interface (GUI)

306______________________________ Chapter 9. Operating systems architecture

Thus, programs written to these standards will run the same on all POSIX-compliant systems. However, the standards are partly just advisory in nature. Some of the standards are described very strictly, while others only superficially reveal the basic requirements. Often software systems are declared to be POSIX-compliant, although they cannot be called such. The reasons lie in the formal approach to implementing the POSIX interface in various operating systems. In Fig. Figure 9.1 shows a typical implementation diagram for a strictly POSIX-compliant application.

Rice. 9.1. Implementation diagram of an application strictly compliant with the POSIX standard

The figure shows that the program uses only POSIX libraries to interact with the operating system. 1 and the standard C RTL library, in which only 110 different functions can be used, also described by the POSIX standard. 1.

Unfortunately, quite often, in order to increase the performance of a particular subsystem or to introduce proprietary technologies that limit the scope of application of the application to the corresponding operating environment, other functions that do not meet the POSIX standard are used during programming.

Implementations of the POSIX standard 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 it, the Windows NT operating system introduced a special API module to support the POSIX standard, operating 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 via WinAPI. Other applications written using WinAPI can pass POSIX information to applications through the standard stdin and stdout I/O stream mechanisms.

Programming examples for different APIs____________________ 307

Programming examples for different APIs

To clearly demonstrate the fundamental differences between the APIs of the most popular modern operating systems for personal computers, let's consider a simple example in which it is necessary to count the number of spaces in text files, the names of which must be specified on the command line. Let's consider two versions of the program: for Windows (using WinAPI) and for Linux (POSIX API).

Since we are interested in working with parallel tasks, let us assume that when the program is executed, for each of the files listed on the command line, its own process or execution thread (task) is created, which, in parallel with other processes (threads), performs the work of counting spaces in “its” file. The result of the program will be a list of files with the number of spaces counted for each.

Particular attention should be paid to the fact that the implementations of programs for solving this problem given below are not the only possible ones. Both operating systems in question have different methods for working with the file system and managing processes. In this case, only one option is considered, but the most typical one for the corresponding API interface.

In order to make it more convenient to compare this (Listing 9.1) and the following (Listing 9.2) programs, and also taking into account that the task does not require a window interface for its solution, only those API calls that do not affect the graphical interface are used in the text. Of course, nowadays it is rare that an application does not use the capabilities of the GUI, but in our case you can immediately see the difference in the organization of parallel operation of the launched calculations.

Subject: Operating systems.
Question: No. 8

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

OS design principles:

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

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

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

2.) The principle of functional selectivity– the OS allocates a certain part of important modules that must be permanently located in RAM for more efficient organization of the computing process. This part of the OS is called the kernel, since it is the basis of the system. When forming the composition of the core, two contradictory requirements have to be taken into account. On the one hand, the kernel should include the most frequently used system modules, on the other hand, the number of modules should be such that the amount of memory occupied by the kernel is not too large. In addition to the program modules that are part of the kernel and are permanently located in RAM, there may be many other system program modules, which are called transit. Transit 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. As a result of generation, a full version of the OS is obtained. The generated OS version is a collection of system sets of modules and data.

4.) The principle of functional redundancy: This principle takes into account the possibility of carrying out the same work by different means. The OS may include several types of monitors (supervisor modules that manage one or another type of resource), various means of organizing communications between computing processes. The presence of several types of monitors and several file management systems allows users to quickly and most adequately adapt the OS to a specific computer system configuration, ensure the most efficient loading of hardware when solving a specific class of problems, and 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 lies in the fact that the connection of programs with specific devices is carried out not at the level of program translation, 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-level 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 level of libraries and system calls. In this case, it is necessary to recompile the existing source texts into a new executable module.

It is much more difficult to achieve binary compatibility between processors based on different architectures. In order for one computer to execute the programs of another (for example, it is advisable to execute a program for a PC such as an IBM PC on a PC such as an Apple Macintosh), this computer must work with machine instructions that are initially incomprehensible to it. In this case, a 680x0 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: An open operating system is available for analysis by both users and system specialists maintaining the computer system. An expandable (modified, developed) OS allows you not only to use generation capabilities, but also to introduce new modules into its composition, improve existing ones, etc. In other words, it should be possible to easily make additions and changes when necessary without compromising the integrity of the system. Excellent opportunities for expansion are provided by the client-server approach to structuring the OS using micro-kernel technology. In accordance with this approach, the OS is built as a set of privileged control programs and a set of unprivileged services (servers). The main part of the OS remains unchanged, and at the same time new servers can be added or old ones improved. This principle is sometimes interpreted as system expandability.

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

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

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

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

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

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

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

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

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

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

language for describing system API functions.

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

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

This module provides conversion and 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...

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

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

What is POSIX?

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

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

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

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

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

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

- (IPAEng|ˈpɒzɪks) or Portable Operating System Interface cite web | title = POSIX | url = http://standards.ieee.org/regauth/posix/ | work = Standards | publisher = IEEE] is the collective name of a family of related standards specified by the IEEE ... Wikipedia

POSIX- est le nom d une famille de standards définie depuis 1988 par l Institute of Electrical and Electronics Engineers et formellement désignée IEEE 1003. Ces standards ont émergé d un projet de standardization des API des logiciels destinés à… … Wikipédia en Français

Posix- est le nom d une famille de standards définie depuis 1988 par l IEEE et formellement désignée IEEE 1003. Ces standards ont émergé d un projet de standardization des API des logiciels destinés à fonctionner sur des variantes du système d… … Wikipédia en Français

POSIX- es el acrónimo de Portable Operating System Interface; la X viene de UNIX como seña de identidad de la API. El término fue sugerido por Richard Stallman en respuesta a la demanda de la IEEE, que buscaba un nombre fácil de recordar. Una traducción … Wikipedia Español

POSIX- , 1986 im Standard 1003.1 der IEEE niedergelegte Spezifikation für Zugriffe auf Systemfunktionen unter Unix. Sowohl Unix Sy…Universal-Lexikon

POSIX- standartai statusas T sritis informatika apibrėžtis Standartų grupė, apibrėžianti operacinės sistemos sąsajas tarp joje veikiančių programų bei tarnybų. Pirmuosius standartus sukūrė Elektros ir elektronikos inžinierių institutas (IEEE) Linux… … Enciklopedinis kompiuterijos žodynas

POSIX- es el acrónimo de Portable Operating System Interface, viniendo la X de UNIX con el significado de la herencia de la API (Se traduciría como Sistema Operativo Portable basado en UNIX). Estos son una familia de estándares de llamadas al sistema… … Enciclopedia Universal

POSIX- (Portable Operating System Interface based on uniX) n. collection of standards for operating systems that are based on Unix (Computers) ... English contemporary dictionary

POSIX

Posix- Das Portable Operating System Interface (POSIX [ˈpɒsɪks]) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Application und dem… … Deutsch Wikipedia

Books

• , Stephen A. Rago, W. Richard Stevens. "UNIX. Professional Programming" is a detailed reference guide that for 20 years has been helping professional C programmers write exclusively...
• UNIX. Professional Programming by Stevens W. Richard, Rago Steven A. This book is deservedly popular with serious programmers around the world because it contains the most important and practical information about managing UNIX and Linux kernels. Without these...