Alexey Fedorchuk
2005

One of the distinctive features logical device file system The operating system of the POSIX family is their hierarchical, or tree-like, organization (although, as I already said, the tree looks a little strange). That is, there are no designations (for example, alphabetic or any other) for individual media and their sections, as in DOS or Windows of any kind: they are all included in a single structure as subdirectories of the main directory. called root. The process of mounting file systems on independent physical media (and their partitions) to the root of the file tree is called mounting, and the subdirectories whose contents they comprise are called mount points.

Historically, Unix has developed a certain directory structure, very similar in different representatives of this family in general outline, but slightly different in details. In particular, the file hierarchy in BSD systems is almost identical, differing from that in Linux. And in the latter, significant differences are found between different distributions. To the point that the structure file hierarchy is one of the distribution-specific features.

This state of affairs makes it difficult to write cross-platform applications. And therefore there is and is actively developing a file hierarchy standardization project - FHS (Filesystem Hierarchy Standard).

The FHS project was originally aimed at streamlining the directory structure of numerous Linux distributions. Later it was adapted for other Unix-like systems (including the BSD clan). And now there are active (but not very successful) efforts to make it a standard for POSIX systems, not only in name, but in fact.

The FHS standard rests on two fundamental principles - a clear separation in the file hierarchy of shared and non-shared directories, on the one hand, and immutable and mutable, on the other.

The contrast between shared and non-shared directories is due to the inherently networked nature of Unix. That is, data related to the local machine (for example, configuration files for its devices) should be located in directories separate from those whose contents are accessible from other machines on the network, local or global (an example of which is not only user data, but also programs) .

The essence of the contrast between immutable and mutable directories can be easily explained with an example. Thus, the same general user programs must be immutable in nature (or rather, available for modification only to the system administrator, but not to the user himself who uses them in his work). At the same time, these programs, during their operation, generate not only data files, say, texts or images (their variable nature is clear without comment), but all kinds of service information, such as log files, temporary files, and the like). Which should be grouped in directories separated from the actual executable files of the programs required to run the libraries, configuration files etc.

However, despite active promotion in many of the most common Linux distributions, FHS has not achieved the status of a true standard. There are quite a few Linux distributions, which do not use some of its provisions. And it only partially correlates with the traditional file hierarchy of BSD systems.

And the reason is that FHS ignores another contrast that is very important for the user: the contrast between easily recoverable parts of the file system and those of its components that are difficult to recover or cannot be recovered at all.

The first, oddly enough, includes the base system itself: after all, reinstalling it from the distribution media in the event of a fatal crash is not so difficult. The hard-to-recover parts of the file system obviously include user data: even if they are regularly backed up (and how many users are so careful?), unrolling them from archives will take a lot of time (and will almost inevitably entail some losses).

In addition, in BSD systems and Source Based Linux distributions, I would classify as hard-to-restore directories everything related to package management - the FreeBSD ports tree or pkgsrc in NetBSD (and systems that borrowed it), their analogues in Linux distributions, the actual sources of ported programs , and the source codes of the system too. Because, even if all this is available in the distribution, these file system components are usually supported by the user in current state by synchronizing over the Network with the project servers (otherwise their use is meaningless). And their loss will entail both temporary (especially with a modem connection) and financial (few people are happy owners of free Internet access) losses.

Strict adherence to the concept of separating shared and non-shared, immutable and immutable, recoverable and non-recoverable directories from each other allows, within a single tree-like file hierarchy, to isolate its individual branches physically - that is, in the form of independent file systems located on isolated devices (disks, disk sections, slices, partitions, etc.). There are many reasons for this - increasing speed, increasing reliability, and simply considerations of convenience - but we won’t talk about them now. Because in this moment All that matters to us is that these branches of the file tree must be incorporated into the overall file system.

A typical set of POSIX system directories

As a matter of fact, for operation it is absolutely necessary to have only one file system - the one that is mounted in the root directory of the file tree (a kind of analogue of the world tree Yggdrassil). The root directory and its indispensable branches must necessarily form a single file system located on one medium - a disk, disk partition, software or hardware RAID array, or logical volume in the sense of LVM. And it should contain all the components necessary to start the system and, ideally, nothing more.

You can view the composition of the root directory with the command

$ls -1/

which on any POSIX system will show a certain minimum gentleman's set of directories:

Bin/ boot/ etc/ root/ sbin/

They contain all the files without which the system cannot exist. Other directories are something like this:

Home/ mnt/ opt/ tmp/ usr/ var/

They a) are not required (at least theoretically - in practice it is difficult to do without them), b) not each of them is present in all systems and distributions, and c) each of them can be (and often is - if you do everything wisely) ) the mount point of its own branch of the file tree.

In addition, in most cases, in the root of the file system of POSIX-compatible operating systems there are two more subdirectories:

Dev/proc/

These are usually the mount points for virtual file systems - devices and processes, respectively (although if a device file system is not used, the /dev directory must be a component of the root file system. Finally, on Linux systems, as a rule, the root of the file tree lies there is also a /lib directory, intended for the main system libraries.And when using the udev mechanism, there is also an inevitable /sys directory, in which the sysfs virtual file system is mounted.

Root file system

The root file system is non-shared (that is, not intended to be shared between different machines on the network) and immutable (that is, changes to it can only be made by the system administrator, but not by user programs and, especially not by users). Moreover, it is highly not recommended to create subdirectories in it beyond those provided for by the standard (and listed above).

The content of the root file system is selected in such a way that the machine can start and retain minimal functionality even when emergency boot(or in single-user mode) when all other file systems are not mounted (and, accordingly, branches such as /usr or /var may not be accessible.

In accordance with this, the start of the machine is ensured by the /boot and /etc directory files. The first contains the system kernel - a "special purpose" executable file - and everything that is required to load it: in Linux, for example, this is the system map (file /etc/System.map), and in FreeBSD - loadable kernel modules. However, sometimes the kernel is located directly at the root of the file system, and then the /boot directory may be absent altogether, and the /modules directory may be allocated for kernel modules.

The /etc directory is intended for system-wide configuration files that determine the boot conditions. Its content very much depends on the system (and in Linux, also on the distribution), and therefore I will not consider it here - I will have to return to this topic more than once.

The minimum required functionality is provided by the contents of the /bin and /sbin directories - they contain executable files of the most important user and system programs, respectively, the very ones that will allow you to carry out a set of repair and rescue measures and bring the machine back to human form after a failure.

Distribution of system and user programs by subdirectories of the root - quite conditionally. None of these commands are truly intended to solve user problems. It’s just that the /bin directory contains administration commands that are accessed from time to time (or can be accessed) and regular user, and the sbin directory is for commands that the user is not supposed to know about. And which, in most cases, he will still not be able to use due to the lack of appropriate permissions (for example, the required access rights to device files).

To run POSIX programs (including those collected in the /bin and sbin directories), as a rule, you need access to the functions of system-wide libraries (primarily the main glibc library). And therefore (almost) an indispensable component of the root directory is the /lib subdirectory, in which they are collected.

In Linux, the /lib directory serves another important purpose - its subdirectory (/lib/modules) contains loadable kernel modules (in FreeBSD their place is the /boot/kernel directory).

In FreeBSD, the /lib directory is not found in the root file system - the corresponding components are located here in /usr/lib (see below). This is because, historically, FreeBSD built critical system-wide programs so that the library functions they required were built into their executables (known as static linking, discussed in Chapter 14). In FreeBSD branch 5, programs from the /bin and /sbin directories are linked dynamically, that is, in the absence of the /usr directory (and in Free this is almost always a separate branch of the file system), they do not function. To compensate for this, a non-standard /restore directory is provided, containing the same programs, but statically linked (as the name of the directory implies, the only purpose of its contents is emergency rescue work).

And finally /root . This is the usual home directory of the user of the same name, that is, the system administrator. Since it doesn't do any practical work (or at least it shouldn't), its contents are just the superuser's own configuration files (user's command shell, favorite editor, etc.).

Branch /usr

Historically, the /usr directory was for user programs and data. These functions are now split between the /usr/local and /home directories (although the latter is still a symlink to /usr/home by default on FreeBSD). The /usr directory - not changeable, but shared - serves as a container for the main part of application programs and everything that relates to them - source codes, configuration files, shared libraries, documentation and the like.

The composition of the /usr directory differs significantly between BSD systems and Linux. In the first, only integral parts of the operating system are placed in it (what in FreeBSD is united by the concept of Distributions). Applications installed from ports or packages are registered in the /usr/local subdirectory, which can represent a separate branch of the file tree.

In Linux, the /usr directory serves as a repository for all programs (and their components) that are standardly included in the distribution. And the /usr/local subdirectory is usually intended for programs that are independently compiled from sources.

In any case, the usual composition of the /usr directory is as follows (as output from the ls -1 command):

X11R6/ bin/ etc/ include/ lib/ libexec/ local/ sbin/ share/ src/

As already mentioned, the /usr/local subdirectory is a separate branch of the file tree, and therefore will be considered separately. The purpose of other directories is as follows:

• /usr/bin and /usr/sbin are intended for executable files of user and system programs (here the boundary between them is even more arbitrary than in the case of the root directory), the purpose of which goes beyond ensuring the basic functioning of the system;
• /usr/etc is for configuration files of individual applications;
• /usr/include contains the so-called header files necessary for linking executable files with library components;
• /usr/lib and /usr/libexec are directories for shared libraries on which user applications depend;
• /usr/share - a container for a wide variety of so-called. architecturally independent components: here you can see documentation in different formats, examples of configuration files, data used by console management programs (fonts, keyboard layouts), and descriptions of time zones;
• /usr/src - directory for source codes; in Linux, only the source codes of the system kernel(s) are normally placed here, in BSD clones - full set the source code of the complex, which in FreeBSD is called Distributions; As a rule, it is not advisable to place the source codes of self-assembled programs here;
• /usr/X11R6 - directory for components of the X window system - executable files (/usr/X11R6/bin), libraries (/usr/X11R6/lib), headers (/usr/X11R6/include), documentation (/usr/X11R6/ man); X application files should not be placed here (with the possible exception of window managers) - their place is in /usr, /usr/local or /opt, depending on the system.

In addition, the /usr directory may contain subdirectories /usr/var and /usr/tmp - usually symbolic links to the corresponding branches of the root directory. And in some Linux distributions, the main system-wide documentation - man pages - are placed directly in /usr (in the /usr/man subdirectory).

Finally, on BSD systems and some Source Based Linux distributions (for example, Gentoo), the /usr directory contains a subdirectory for the package management system - FreeBSD and OpenBSD ports (/usr/ports), their analogues on other systems (/usr/portage in Gentoo). Although from the point of view of following the letter and spirit of the FHS standard (it itself does not mention a word about ports and similar systems), a more logical place for their placement would be the /var directory (see below) - and this is exactly what is done in distributions such as CRUX and Archlinux.

Branch /usr/local

As already mentioned, the /usr/local branch in Linux is intended for programs that are independently compiled from source code (not included in this distribution). And in FreeBSD, it serves as a container for most user applications - almost everything that goes beyond Distributions and is installed from packages or ports. Accordingly, the directory structure as a whole follows that of the /usr branch (with obvious exceptions):

Bin/ etc/ include/ lib/ man/ sbin/ share/

The contents of the subdirectories are also similar: executable program files (/usr/local/bin and /usr/local/sbin), their configs (/usr/local/etc), libraries with which they are linked, and their header files (/usr/ local/lib and /usr/local/include , respectively), man pages (/usr/local/man) and all sorts of architecture-independent stuff (/usr/local/share), including documentation in other formats.

Branch /opt

The /opt directory is provided by the FHS standard, but is not actually used in all Linux distributions, and is completely absent on BSD systems. However, more and more programs are written with a default installation in mind.

Historically, the /opt directory was intended in Linux for commercial applications and all kinds of programs of a not entirely free nature. Nowadays, its purpose is to host large self-sufficient software complexes, such as the Qt library, KDE with all its components and applications, OpenOffice.org and the like. The directory structure should be like this: /opt/pkg_name. This is what it looks like on my system (Archlinux):

$ ls -1 /opt gnome/ kde/ OpenOffice.org1.1.2/ qt/

Each of the subdirectories has its own internal structure:

$ ls -1 /opt/* /opt/gnome: bin/ lib/ man/ share/ /opt/kde: bin/ etc/ include/ lib/ share/ /opt/OpenOffice.org1.1.2: help/ LICENSE LICENSE. html program/ README README.html setup@ share/ spadmin@ THIRDPARTYLICENSEREADME.html user/ /opt/qt: bin/ doc/ include/ lib/ mkspecs/ phrasebooks/ plugins/ templates/ translations/

The purpose of the subdirectories inside /opt/pkg_name is easy to guess by analogy with /usr and /usr/local. For example, /opt/kde/bin is for executable files of the KDE system and its applications, /opt/kde/etc is for its configuration files, /opt/kde/include is for header files, /opt/kde/lib is for libraries and /opt/kde/share - for shared files, including documentation. KDE does not have documentation in man format, but if it does exist, then (as in the case of Gnome - I did not install it, this is what Gimp and similar Gtk applications pulled) you can see the subdirectory /opt/pkg_name/man .

You can see that the structure of the /opt directory deviates from the historical (and internally justified POSIX-tradition of combining similar components into directories - executable files, libraries, etc. And with a large number of programs installed in it, it creates certain difficulties: you either have to overload the variable with values $PATH , which provides quick access to commands (which will be discussed in Chapter 12), or create a special directory /opt/bin and place symbolic links to executable program binaries in it. Therefore, in a number of Linux distributions (for example, in CRUX), the directory / opt is not used as a matter of principle, as in all BSD systems. It is quite possible that it is better this way...

/var branch

As the name implies, the /var directory is intended to store mutable files generated during the normal operation of various programs - software (for example, browser) caches, log files, print spooling and mail systems, mailboxes, descriptions running processes and so on. In particular, it is in the /var directory that so-called dumps are placed - state snapshots random access memory, generated during an abnormal shutdown to identify its causes. A distinctive feature of all these components is their changeable nature during a work session and the fact that they, nevertheless, must be preserved when the system is rebooted.

The internal structure of /var varies greatly from system to system, and therefore I will not dwell on the details of its structure. I will only note that this directory is a logical place for placing components of all kinds of port-like package management systems, as is done, for example, in the Archlinux distribution, where the /var/abs subdirectory is reserved for it (abs - Archlinux Building System).

Directory /mnt

The /mnt directory is intended for mounting temporarily used file systems, located, as a rule, on removable media. In a fully installed system, it is usually empty, and its structure is not regulated in any way. The user is free to create subdirectories in it for individual types of media. For example, on my system this is /mnt/cd, /mnt/dvd, /mnt/usb and /mnt/hd - for CDs, DVDs, flash drives and removable hard drives.

In FreeBSD, the default directories for mounting CDs and floppy disks are /cdrom and /floppy directly in the root directory. Which is not entirely consistent with the standard, but is logical in its own way - the mount points of devices that exist (like a CD ROM) or until recently existed (a floppy drive) in any machine are placed in the root.

Branch /home

The /home directory is intended to contain user home directories. Its content is not regulated in any way, but usually it looks like /home/(username1,...,username#) . Although on large systems with many users their home directories may be grouped together.

The /home directory can contain the home directories of not only real but also some virtual users. So, if the machine is used as a web or ftp server, you can see subdirectories such as /home/www or /home/ftp, respectively.

Branch /tmp

The only thing left to talk about is the directory for storing temporary files - /tmp. Like /var components, they are generated by various programs as part of their normal functioning. But, unlike /var , /tmp components are not expected to be saved outside the current session. Moreover, all system administration manuals recommend cleaning this directory regularly (for example, when restarting the machine) or periodically. And therefore, as /tmp, it is advisable to mount file systems in RAM - tmpfs (in Linux) or mfs (in FreeBSD). In addition to the fact that this ensures that its contents are cleared upon reboot, it also improves performance, for example, the compilation of programs whose temporary products are not written to disk, but are placed in a virtual directory like /tmp/obj.

On many systems you will see directories like /usr/tmp and /var/tmp. These are usually symbolic links to /tmp.

File system partitioning strategy

In conclusion of the conversation about file hierarchy, it should be emphasized that it is guaranteed that only the directories listed in paragraph should be located on one file system (figuratively speaking, on one disk partition, although this is not entirely accurate) Root file system. All other directories - /usr, /opt, /var, /tmp and, of course, /home can represent mount points for independent file systems on separate physical media or their partitions.

Moreover, on a local network, these directories may well be located even on different machines. So, one computer acting as an application server can contain the /usr and /opt directories shared on the network, another - a file server - can contain all user home directories, and so on.

All that remains is to decide which file systems are appropriate to isolate from the general file tree, and why to do this. The answer to these questions very much depends on the OS used, and in the case of Linux, also on its distribution. Nevertheless, general principles for separating file systems can be outlined. For this reason, we should remember the contrast between, on the one hand, immutable and mutable directories, and on the other, easily recoverable, difficult to recover and practically unrecoverable data. Let's make this attempt in relation to a user's desktop - in the case of a server, the calculations will be significantly different.

Obviously, the root file system, consisting of the /bin, /boot, /etc, /root, /sbin directories, containing data that can be easily restored from the distribution media and is practically unchangeable, should be located on an isolated disk partition. On Linux, this should also include a /lib directory. On the other hand, when using GRUB as a bootloader (regardless of the operating system), it is recommended to place the /boot directory on a separate partition.

In old sources about Linux, you can read about another reason for allocating a partition for the /boot directory, and at the very beginning of the disk: due to the impossibility of loading the kernel by the Lilo program from a cylinder number higher than 1023. In modern versions of bootloaders there are no such restrictions. However, if a partition for /boot is already being created, it is reasonable to make it the first one on the disk, and place the swap partition directly behind it: this will add five cents of performance when performing swapping.

And one more thing from the field of history: the requirement that the root and boot partitions were certainly primary, also removed long ago. And these file systems may well fit on logical partitions inside the Extended Partition.

It is equally clear that the modifiable branches of the file system - the /var and /tmp directories - must be moved outside the root partition. Moreover, the latter, as has been said many times before, is generally advisable to place it on a file system in RAM (tmpfs or mfs). In case the /var directory contains subdirectories for port-like package management systems, like /var/abs , /var/cache/pacman/src and /var/cache/pacman/pkg in Archlinux, these should also form separate file systems

Now - the /usr directory, containing either the components of the base system (as in BSD), or the bulk of user applications (as in most Linux distributions). It contains easily recoverable data and, to be fair, should be practically unchangeable, and therefore, of course, deserves to be allocated in a separate section. Moreover, from its composition it is advisable to isolate, on the one hand, the subdirectories /usr/X11R6 and /usr/local, on the other - subdirectories for port-like package management systems: /usr/ports, /usr/pkgsrc and /usr/pkg in BSD systems , /usr/portages on Gentoo Linux, and so on. Moreover, the latter should be separated into subdirectories for storing sources downloaded from the network when building ports - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles and the like.

In BSD systems, in addition, from the /usr directory it makes sense to select subdirectories /usr/src and /usr/obj containing the source code of the basic components (including the kernel) and intermediate products of their compilation, formed as a result of the make buildworld and make buildkernel procedures .

And finally, the /home directory, which contains changeable and often unrecoverable data, must be removed from the root of the file hierarchy. Moreover, I always try to place it either on a separate slice (in BSD) or on the primary partition (in Linux).

The proposed scheme for separating file systems may seem unnecessarily complicated. However, it guarantees the isolation of easily recoverable, difficult to recover and unrecoverable data, which will facilitate system reinstallation in case of emergency, and even migration from system to system.

Its additional advantage is that for individual branches of the file tree, depending on the nature of the data located on it, in Linux you can select a physically optimal file system. For example, for the /boot partition there is no point in using anything other than Ext2fs. It is usually recommended to format the root partition in the reliable and most compatible Ext3fs. For directories with a huge number of small files, such as /var/abs in Archlinux, /usr/portages in Gentoo, it is advisable to use ReiserFS: after all, skillful handling of small files is its profile. And in the /home directory, where huge multimedia files can appear (and which itself is usually very large), XFS may come in handy (although, as measurements show, ReiserFS looks quite decent here). Such measures can help improve both the reliability of data storage and the speed of file operations.

Users of BSD operating systems are bound to FFS file systems without alternative. However, they also have room for maneuver. Firstly, by varying the block and fragment sizes of individual file systems, which contributes either to the performance of disk operations or to saving disk space. And secondly, some branches of the file tree (such as /tmp or /usr/obj, contrary to recommendations, can be safely mounted in purely asynchronous mode, gaining a percentage or two in performance.

POSIX and RT OS: an attempt at systematization

Sergey Zolotarev, Nikolay Gorbunov

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

As an introduction: why is software interface standardization necessary?

One of the most important properties of the POSIX standard is that it defines a "standardized software interface", which developers of complex software and hardware 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 costs is due to slowdown 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 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 is the key organization in the preparation of international standards for information technology. In this area there is a joint technical committee on information technology, JTC 1, formed in 1987 in accordance with an agreement between IEC and ISO. JTC1 has 17 subcommittees overseeing all developments - from software to programming languages, computer graphics and image editing, interconnection of equipment and security methods.

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 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 (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 interface operating systems 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 in English language 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:

• 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 platform Intel company 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.

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 source code(not to the binaries that are assembled from these very sources). Now let's find out what an “interface” is. In programming, an "interface" is how your code interacts with other code. The interface expects your code to provide certain information. Your code, in turn, expects to receive certain information from the interface. 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, otherwise known as interfaces). command line), 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 that 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 has been helping for 20 years professional programmers write in C language 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...

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

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

NOTE

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

Then the IEEE 1003.1-1990 standard (356 pages) came out. It was also the international standard ISO/IEC 9945-1:1990. Compared to the 1988 version, changes in the 1990 version were minimal. 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 Unix System V) and about a hundred utilities (programs usually 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 working group P1003.4: 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.

There are plans to 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. ABOUT current state standards can be found at http://www.pasc.org/standing/sd11.html.