- (IPAEng | ˈpɒzɪks) ou Portable Operating System Interface cite web | titre = POSIX | url = http://standards.ieee.org/regauth/posix/ | travail = Normes | éditeur = IEEE] est le nom collectif d'une famille de normes connexes spécifiées par l'IEEE ... Wikipedia

POSIX- est le nom d'une famille de normes définies depuis 1988 par l Institute of Electrical and Electronics Engineers et formellement désigné IEEE 1003. Ces normes ont émergé d'un projet de normalisation des API des logiciels destinés à…… Wikipédia in English

Posix- est le nom d'une famille de normes définies depuis 1988 par l IEEE et officiellement désignée IEEE 1003. Ces normes ont émergé d'un projet de normalisation des API des logiciels destinés à fonctionner sur les variantes du système d…… en Wikipédia

POSIX- c'est l'acrónimo de l'interface du système d'exploitation portable ; la X viene de UNIX como seña de identidad de la API. El termino fue sugerido por Richard Stallman en réponse à la demande de l'IEEE, que buscaba un nombre fácil de recordar. Una traducción… Wikipedia Español

POSIX-, 1986 im Standard 1003.1 der IEEE niedergelegte Spezification 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) Linukso ... ... 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- (Interface de système d'exploitation portable basée sur uniX) n. collection de normes pour les systèmes d'exploitation basés sur Unix (ordinateurs) ... dictionnaire anglais contemporain

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 Applikation und dem…… Deutsch Wikipedia

Livres

• , Stephen A. Rago, W. Richard Stevens. UNIX. Professional Programming est un guide de référence complet qui aide les programmeurs professionnels à écrire exclusivement en langage C depuis 20 ans...
• UNIX. Programmation professionnelle, Stevens W. Richard, Rago Steven A. Ce livre est à juste titre populaire auprès des programmeurs sérieux du monde entier, car il contient les informations les plus importantes et les plus pratiques sur la gestion des noyaux UNIX et Linux. Sans ces...

Alexey Fedorchuk
année 2005

L'une des caractéristiques distinctives de la structure logique du système de fichiers des systèmes d'exploitation de la famille POSIX est leur organisation hiérarchique ou arborescente (bien que, comme je l'ai dit, l'arborescence semble un peu étrange). C'est-à-dire que, comme dans DOS ou Windows de toute sorte, il n'y a pas de désignation (par exemple, alphabétique ou autre) pour les supports individuels et leurs partitions : ils sont tous inclus dans une structure unique en tant que sous-répertoires du répertoire principal. appelé la racine. Le processus d'attachement des systèmes de fichiers sur des supports physiques indépendants (et leurs partitions) à la racine de l'arborescence de fichiers est appelé montage, et les sous-répertoires qu'ils contiennent sont appelés points de montage.

Historiquement, Unix a développé une structure de répertoires spécifique qui est très similaire à travers la famille en termes généraux, mais légèrement différente dans les détails. En particulier, la hiérarchie des fichiers sur les systèmes BSD est presque identique, mais différente de celle sur Linux. Et dans ce dernier, des différences significatives sont trouvées entre les différentes distributions. Dans la mesure où la structure de la hiérarchie des fichiers est l'une des caractéristiques propres à la distribution.

Cet état de fait rend difficile l'écriture d'applications multiplateformes. Et par conséquent, il existe et développe activement un projet de normalisation de la hiérarchie des fichiers - FHS (Filesystem Hierarchy Standard).

Le projet FHS visait principalement à rationaliser la structure des répertoires dans de nombreuses distributions Linux. Plus tard, il a été adapté pour d'autres systèmes de type Unix (y compris le clan BSD). Et maintenant, il y a des efforts actifs (mais pas très réussis) pour en faire la norme pour les systèmes POSIX, non seulement en nom, mais aussi en fait.

La norme FHS repose sur deux principes fondamentaux - une séparation claire dans la hiérarchie des fichiers des répertoires partagés et non partagés, d'une part, et immuables et mutables, d'autre part.

Le contraste entre les répertoires partagés et non partagés provient de la nature réseau inhérente à Unix. C'est-à-dire que les données relatives à une machine locale (par exemple, les fichiers de configuration de ses périphériques) doivent être situées dans des répertoires distincts de ceux dont le contenu est disponible à partir d'autres machines du réseau, locales ou globales (dont un exemple n'est pas uniquement utilisateur données, mais aussi des programmes) ...

L'essence de l'opposition entre les répertoires immuables et mutables est facile à expliquer avec un exemple. Ainsi, les mêmes programmes utilisateur généraux, de par leur nature, devraient être immuables (ou plutôt, disponibles pour modification uniquement pour l'administrateur système, mais pas pour l'utilisateur lui-même qui les utilise dans son travail). Dans le même temps, ces programmes au cours de leur travail génèrent non seulement des fichiers de données, par exemple des textes ou des images (leur nature variable est claire sans commentaires), mais toutes sortes d'informations de service, telles que des fichiers journaux, des fichiers temporaires, etc.) . Qui doivent être regroupés dans des répertoires séparés des fichiers de programmes exécutables réels requis pour les exécuter, des bibliothèques, des fichiers de configuration, etc.

Néanmoins, malgré une promotion active dans de nombreuses distributions Linux parmi les plus courantes, le FHS n'a pas acquis le statut de véritable standard. Il existe de nombreuses distributions Linux qui n'utilisent pas certaines de ses dispositions. Et cela n'est que partiellement corrélé avec la hiérarchie de fichiers traditionnelle des systèmes BSD.

Et la raison en est que le FHS ignore une autre opposition, qui est très importante pour l'utilisateur : l'opposition des parties facilement récupérables du système de fichiers, et celles de ses composants qui sont difficiles à récupérer ou pas du tout récupérables.

Le premier, assez curieusement, peut être attribué au système de base lui-même : après tout, le réinstaller depuis le support de distribution, en cas de crash fatal, n'est pas si difficile. Les parties difficiles à récupérer du système de fichiers incluent évidemment les données des utilisateurs : même si elles sont régulièrement sauvegardées (et combien d'utilisateurs sont si prudents ?), les déployer à partir d'archives prendra beaucoup de temps (et entraînera presque inévitablement des pertes).

De plus, dans les systèmes BSD et les distributions Linux basées sur la source, je classerais tout ce qui concerne la gestion des paquets comme des répertoires difficiles à récupérer - l'arborescence des ports FreeBSD ou pkgsrc dans NetBSD (et les systèmes qui l'ont emprunté), leurs homologues dans les distributions Linux, les sources réelles des programmes portés, ainsi que le code source du système. Car, même si tout cela se trouve sur le kit de distribution, ces composants du système de fichiers, en règle générale, sont tenus à jour par l'utilisateur en se synchronisant sur le réseau avec les serveurs du projet (sinon leur utilisation n'a pas de sens). Et leur perte entraînera des pertes à la fois temporaires (surtout avec une connexion commutée) et financières (peu de gens sont les heureux propriétaires d'un accès Internet gratuit).

Le strict respect du concept de séparation des répertoires partagés et non partagés, immuables et immuables, récupérables et non récupérables les uns des autres permet, au sein d'une même hiérarchie de fichiers arborescente, de séparer physiquement ses branches individuelles - c'est-à-dire sous la forme de systèmes de fichiers indépendants situés sur des périphériques isolés (disques, partitions de disque, tranches, partitions, etc.). Il y a plusieurs raisons à cela - à la fois une augmentation des performances et une augmentation de la fiabilité, et juste des considérations de commodité - mais nous n'en parlerons pas maintenant. Car pour le moment, la seule chose importante pour nous est que ces branches de l'arborescence des fichiers soient incorporées dans le système de fichiers commun.

Ensemble de répertoires système POSIX typique

En fait, pour le fonctionnement, il est absolument nécessaire d'avoir un seul système de fichiers - celui qui est monté dans le répertoire racine de l'arbre de fichiers (une sorte d'analogue de l'arbre du monde Yggdrassil). Le répertoire racine et ses branches indispensables doivent constituer un système de fichiers unique situé sur un support - un disque, une partition de disque, une matrice RAID logicielle ou matérielle, ou un volume logique au sens de LVM. Et il devrait contenir tous les composants nécessaires pour démarrer le système et, idéalement, rien de plus.

Vous pouvez visualiser la composition du répertoire racine avec la commande

$ ls -1 /

qui, sur n'importe quel système POSIX, affichera un ensemble minimal de répertoires pour gentleman :

Bin / boot / etc / root / sbin /

C'est en eux que sont rassemblés tous les fichiers, sans lesquels le système ne peut exister. Les autres répertoires ressemblent à ceci :

Accueil / mnt / opt / tmp / usr / var /

Ils ne sont a) pas nécessaires (du moins en théorie - il est pratiquement difficile de s'en passer), b) ils ne sont pas tous présents dans tous les systèmes et distributions, et c) chacun d'eux peut être (et est souvent - si vous faites tout selon votre esprit) le point de montage de sa propre branche de l'arborescence des fichiers.

De plus, dans la plupart des cas, il existe deux sous-répertoires supplémentaires à la racine du système de fichiers des systèmes d'exploitation compatibles POSIX :

Dév / proc /

Ce sont généralement les points de montage des systèmes de fichiers virtuels - périphériques et processus, respectivement (bien que, si le système de fichiers des périphériques n'est pas utilisé, le répertoire / dev doit être un composant du système de fichiers racine. Enfin, sur les systèmes Linux, comme une règle, la racine de l'arborescence de fichiers est et le répertoire / lib pour les principales bibliothèques du système, et avec udev, l'inévitable répertoire / sys est l'endroit où le système de fichiers virtuel sysfs est monté.

Système de fichiers racine

Le système de fichiers racine est non partagé (c'est-à-dire qu'il n'est pas destiné à être partagé par différentes machines sur le réseau) et immuable (c'est-à-dire que seul l'administrateur système peut y apporter des modifications, mais pas les programmes utilisateur et, de plus, pas les utilisateurs ). De plus, il est fortement déconseillé d'y créer des sous-répertoires en plus de ceux fournis par la norme (et listés ci-dessus).

Le remplissage du système de fichiers racine est sélectionné pour que la machine puisse démarrer et conserver une fonctionnalité minimale même pendant le démarrage d'urgence (ou en mode mono-utilisateur), lorsque tous les autres systèmes de fichiers ne sont pas montés (et, par conséquent, ses branches telles que / usr ou / var peuvent ne pas être disponibles.

En conséquence, le démarrage de la machine est assuré par les répertoires files/boot et/etc. Le premier contient le noyau du système - un exécutable "à usage spécial" - et tout ce qui est nécessaire pour le charger - sur Linux, par exemple, la carte du système (/etc/System.map), et sur FreeBSD - des modules de noyau chargeables . Cependant, parfois, le noyau est situé directement à la racine du système de fichiers, et le répertoire de démarrage / peut être complètement absent et le répertoire / modules peut être réservé aux modules du noyau.

Le répertoire /etc est destiné aux fichiers de configuration à l'échelle du système qui déterminent les conditions de chargement. Son contenu dépend beaucoup du système (et sous Linux - également du kit de distribution), et je ne le considérerai donc pas ici - je devrai revenir plus d'une fois sur ce sujet.

La fonctionnalité minimale nécessaire est fournie par le contenu des répertoires / bin et / sbin - ils contiennent respectivement les fichiers exécutables des programmes utilisateur et système les plus importants, ceux-là mêmes qui vous permettront d'effectuer un complexe de mesures de réparation et de sauvetage et redonner une forme humaine à la voiture après une panne.

La division des programmes système et utilisateur en sous-répertoires racine est plutôt arbitraire. Aucune de ces commandes n'est vraiment destinée à résoudre les problèmes des utilisateurs. C'est juste que le répertoire / bin contient des commandes d'administration, auxquelles accède de temps en temps (ou peut être accédé) par un utilisateur normal, et le répertoire sbin est destiné aux commandes que l'utilisateur n'est pas censé connaître. Et que, dans la plupart des cas, il ne pourra toujours pas utiliser faute de pouvoirs appropriés (par exemple, les droits d'accès requis aux fichiers de l'appareil).

Pour exécuter des programmes POSIX (y compris ceux compilés dans les répertoires /bin et sbin), en règle générale, vous devez accéder aux fonctions des bibliothèques du système (principalement la bibliothèque principale de la glibc). Et donc le composant (presque) indispensable du répertoire racine est le sous-répertoire /lib, dans lequel ils sont assemblés.

Sous Linux, le répertoire / lib sert un autre objectif important — son sous-répertoire (/ lib / modules) contient des modules de noyau chargeables (sur FreeBSD, leur place est / boot / kernel).

FreeBSD ne détecte pas le répertoire /lib sur le système de fichiers racine - les composants correspondants sont placés ici dans /usr/lib (voir ci-dessous). C'est parce que, historiquement, FreeBSD a construit des programmes majeurs à l'échelle du système afin que les fonctions de bibliothèque dont ils ont besoin soient intégrées dans leurs exécutables (appelées liaisons statiques, qui seront discutées au chapitre 14). Dans FreeBSD 5ème branche, les programmes des répertoires / bin et / sbin sont liés dynamiquement, c'est-à-dire qu'en l'absence du répertoire / usr (et dans Free, il s'agit presque toujours d'une branche séparée du système de fichiers), ils ne fonctionnent pas. Pour compenser cela, il existe un répertoire /restore qui va au-delà des standards, contenant les mêmes programmes, mais liés statiquement (comme le nom du répertoire l'indique, le seul but de son contenu est les opérations de sauvetage).

Enfin, / root. Il s'agit du répertoire personnel habituel de l'utilisateur du même nom, c'est-à-dire de l'administrateur système. Puisqu'il ne fait aucun travail pratique (ou du moins ne devrait pas le faire), son contenu n'est que les propres fichiers de configuration du superutilisateur (le shell de commande de l'utilisateur, l'éditeur favori, etc.).

La branche /usr

Historiquement, le répertoire /usr était destiné aux programmes et données utilisateur. Ces fonctions sont désormais réparties entre /usr/local et /home (bien que ce dernier soit désormais un lien symbolique vers /usr/home par défaut sur FreeBSD). Le répertoire /usr - non modifiable, mais partagé - sert de référentiel pour la plupart des programmes d'application et tout ce qui s'y rapporte - code source, fichiers de configuration, bibliothèques partagées, documentation, etc.

La composition du répertoire /usr diffère considérablement entre les systèmes BSD et Linux. Dans le premier, il ne contient que les parties intégrantes du système d'exploitation (ce qui dans FreeBSD est réuni par le concept de Distributions). Les applications installées à partir de ports ou de packages ont leur place dans le sous-répertoire /usr/local, qui peut représenter une branche distincte de l'arborescence des fichiers.

Sous Linux, le répertoire /usr sert de référentiel pour tous les programmes (et leurs composants) inclus dans le kit de distribution. Et le sous-répertoire /usr/local est généralement destiné aux programmes compilés indépendamment à partir des sources.

Dans tous les cas, la composition habituelle du répertoire /usr est la suivante (comme indiqué par la commande ls -1):

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

Comme déjà mentionné, le sous-répertoire /usr/local est une branche distincte de l'arborescence des fichiers et sera donc considéré séparément. L'objet des autres répertoires est le suivant :

• /usr/bin et /usr/sbin sont destinés aux fichiers exécutables des programmes utilisateur et système (ici la frontière entre eux est encore plus arbitraire que dans le cas du répertoire racine), dont la finalité va au-delà d'assurer le fonctionnement de base de le système;
• /usr/etc est destiné aux fichiers de configuration d'application individuels ;
• /usr/include contient les soi-disant fichiers d'en-tête requis pour lier les fichiers exécutables aux composants de la bibliothèque ;
• /usr/lib et /usr/libexec sont des répertoires pour les bibliothèques partagées dont dépendent les applications utilisateur ;
• / usr / share - un référentiel des plus divers, soi-disant. composants indépendants sur le plan architectural : vous pouvez voir ici la documentation dans différents formats, des exemples de fichiers de configuration et des données utilisées par les programmes de gestion de console (polices, dispositions de clavier) et une description des fuseaux horaires ;
• /usr/src - répertoire du code source ; sous Linux, seuls les codes sources du noyau (noyaux) du système sont normalement placés ici, dans les clones BSD - l'ensemble complet des sources du complexe, qui dans FreeBSD s'appelle Distributions ; en règle générale, il n'est pas souhaitable de placer ici les sources des programmes auto-assemblés;
• /usr/X11R6 - répertoire des composants du système de fenêtrage X - fichiers exécutables (/usr/X11R6/bin), bibliothèques (/usr/X11R6/lib), en-têtes (/usr/X11R6/include), documentation (/usr/X11R6/ homme); Les fichiers d'application X ne doivent pas être placés ici (sauf, peut-être, pour les gestionnaires de fenêtres) - leur place est dans /usr, /usr/local ou /opt, selon le système.

De plus, le répertoire /usr peut contenir des sous-répertoires /usr/var et /usr/tmp — généralement des liens symboliques vers les branches correspondantes du répertoire racine. Et sur certaines distributions Linux, la documentation principale à l'échelle du système - les pages de manuel (dans le sous-répertoire / usr / man) - est placée directement dans / usr.

Enfin, sur les systèmes BSD et certaines distributions Linux basées sur la source (par exemple, Gentoo), le répertoire /usr contient un sous-répertoire pour le système de gestion de paquets - les ports FreeBSD et OpenBSD (/usr/ports), leurs équivalents sur d'autres systèmes (/ usr/portage dans Gentoo). Bien que du point de vue de suivre la lettre et l'esprit de la norme FHS (il ne mentionne pas un mot sur les ports et systèmes similaires), un endroit plus logique pour les placer serait le répertoire / var (voir ci-dessous) - et c'est exactement ce qui est fait dans les distributions telles que CRUX et Archlinux.

Succursale / usr / local

Comme déjà mentionné, la branche /usr/local de Linux est destinée aux programmes auto-compilés à partir de sources (non inclus dans ce kit de distribution). Et sur FreeBSD, il sert de base à la plupart des applications de l'utilisateur — presque tout en dehors des distributions et installé à partir de packages ou de ports. En conséquence, la structure du répertoire est globalement similaire à celle de la branche /usr (avec des exceptions compréhensibles) :

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

Le contenu des sous-répertoires est également similaire : les fichiers exécutables du programme (/usr/local/bin et /usr/local/sbin), leurs configs (/usr/local/etc), les bibliothèques avec lesquelles ils sont liés, et leurs fichiers d'en-tête (/ usr/local/lib et/usr/local/include, respectivement), les pages de manuel (/usr/local/man) et toutes sortes de choses indépendantes de l'architecture (/usr/local/share), y compris la documentation dans d'autres formats .

/ Opter une succursale

Le répertoire / opt est fourni par la norme FHS, mais n'est en fait pas utilisé dans toutes les distributions Linux, et dans les systèmes BSD, il est complètement absent. Néanmoins, de plus en plus de programmes sont écrits dans l'attente d'une installation par défaut.

Historiquement, / opt était utilisé sous Linux pour des applications commerciales et toutes sortes de logiciels non libres. De nos jours, son objectif est d'héberger de grands systèmes logiciels autonomes, tels que la bibliothèque Qt, KDE avec tous ses composants et applications, OpenOffice.org et autres. La structure du répertoire doit être / opt / pkg_name. Voici à quoi cela ressemble sur mon système (Archlinux):

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

Chacun des sous-répertoires a sa propre structure interne :

$ ls -1 / opt / * / opt / gnome : bin / lib / man / share / / opt / kde : bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2 : help / LICENSE LICENSE. programme html / README README.html [email protégé] partager / [email protégé] THIRDPARTYLICENSEREADME.html user / / opt / qt: bin / doc / include / lib / mkspecs / phrasesbooks / plugins / templates / translations /

Le but des sous-répertoires à l'intérieur de /opt/pkg_name est facilement deviné par analogie avec /usr et /usr/local. Par exemple, /opt/kde/bin est pour les fichiers exécutables du système KDE et de ses applications,/opt/kde/etc est pour ses fichiers de configuration,/opt/kde/include est pour les fichiers d'en-tête,/opt/kde/lib est pour les bibliothèques, et / opt / kde / share - pour les fichiers partagés, y compris la documentation. Dans KDE, il n'y a pas de documentation au format man, si c'est le cas, alors (comme dans le cas de Gnome - je ne l'ai pas installé, c'est ce que Gimp et les applications Gtk similaires ont extraites) vous pouvez voir le / opt / pkg_name / sous-répertoire man.

Vous pouvez voir que la structure de répertoire / opt s'écarte de la tradition POSIX historiquement établie (et justifiée en interne de combiner des composants du même type dans des répertoires - fichiers exécutables, bibliothèques, etc.) Et avec un grand nombre de programmes installés, il crée certaines difficultés : vous devez soit surcharger le $ PATH, qui fournit un accès rapide aux commandes (qui seront abordées au chapitre 12), soit créer un répertoire spécial / opt / bin et y mettre des liens symboliques vers les binaires du programme exécutable. Par conséquent, dans certaines distributions Linux (par exemple, dans CRUX) le /opt n'est pas utilisé en principe. Comme, d'ailleurs, dans tous les systèmes BSD. Il est fort possible que ce soit mieux ainsi...

/ Filiale Var

Comme son nom l'indique, le répertoire / var est destiné à stocker les fichiers mutables générés au cours de la vie normale de divers programmes - caches de logiciels (par exemple, navigateur), fichiers journaux, spoulage des systèmes d'impression et de messagerie, boîtes aux lettres, descriptions des processus en cours et bientôt. En particulier, c'est dans le répertoire /var que sont placés les soi-disant dumps - des instantanés de l'état de la RAM, générés lors d'un arrêt anormal pour en identifier les raisons. Une particularité de tous ces composants est leur caractère évolutif au cours d'une session et le fait qu'ils doivent néanmoins être conservés lors du redémarrage du système.

La structure interne de /var varie considérablement d'un système à l'autre, c'est pourquoi je ne m'attarderai pas sur les détails de sa structure. Je noterai seulement que ce répertoire est un endroit logique pour placer des composants de toutes sortes de systèmes de gestion de paquets de type port, comme cela se fait, par exemple, dans la distribution Archlinux, où le sous-répertoire /var/abs (abs - Archlinux Building System ) lui est réservé.

Répertoire / mnt

Le répertoire /mnt est destiné au montage de systèmes de fichiers temporairement utilisés, généralement situés sur des supports amovibles. Dans un système tout établi, il est généralement vide et sa structure n'est réglementée d'aucune façon. L'utilisateur est libre d'y créer des sous-répertoires pour certains types de supports. Par exemple, sur mon système, il s'agit de /mnt/cd, /mnt/dvd, /mnt/usb et /mnt/hd - pour les CD, DVD, lecteurs flash et disques durs amovibles.

Sous FreeBSD, les répertoires par défaut pour le montage des CD et des disquettes sont / cdrom et / floppy directement dans le répertoire racine. Ce qui n'est pas tout à fait conforme à la norme, mais à sa manière, c'est logique - les points de montage des périphériques qui existent (comme un CD-ROM) ou qui existaient jusqu'à récemment (un lecteur de disquette) sur n'importe quelle machine sont transférés à la racine.

/ Branche d'accueil

Le répertoire /home sert à héberger les répertoires personnels des utilisateurs. Son contenu n'est en aucun cas réglementé, mais il ressemble généralement à /home/(username1,...,username#). Cependant, dans les grands systèmes avec de nombreux utilisateurs, leurs répertoires personnels peuvent être regroupés.

Le répertoire /home peut contenir les répertoires personnels non seulement d'utilisateurs réels, mais également de certains utilisateurs virtuels. Ainsi, si la machine est utilisée comme serveur Web ou ftp, vous verrez des sous-répertoires tels que / home / www ou / home / ftp, respectivement.

La branche /tmp

Il ne reste plus qu'à parler du répertoire de stockage des fichiers temporaires - /tmp. Comme les composants / var, ils sont générés par divers programmes au cours de leur vie normale. Mais, contrairement à / var, les composants / tmp ne devraient pas persister en dehors de la session en cours. De plus, tous les guides d'administration système recommandent de vider régulièrement (par exemple, lors du redémarrage de la machine) ou périodiquement ce répertoire. Et donc, comme /tmp, il est conseillé de monter les systèmes de fichiers en RAM - tmpfs (sous Linux) ou mfs (sous FreeBSD). En plus du fait que cela garantit que son contenu est effacé au redémarrage, cela contribue également aux performances, par exemple, la compilation de programmes, dont les produits temporaires ne sont pas écrits sur le disque, mais sont placés dans un répertoire virtuel comme / tmp / obj.

Sur de nombreux systèmes, vous verrez des répertoires comme /usr/tmp et /var/tmp. Ce sont généralement des liens symboliques vers / tmp.

Stratégie de partitionnement du système de fichiers

En conclusion de la conversation sur la hiérarchie des fichiers, il convient de souligner que seuls les répertoires énumérés dans le paragraphe Système de fichiers racine... Tous les autres répertoires - /usr, /opt, /var, /tmp et, bien sûr, /home peuvent représenter les points de montage de systèmes de fichiers indépendants sur des supports physiques séparés ou leurs partitions.

De plus, dans un réseau local, ces répertoires peuvent très bien se trouver même sur des machines différentes. Par exemple, un ordinateur faisant office de serveur d'applications peut contenir les répertoires /usr et /opt sur le réseau, un autre un serveur de fichiers contenant tous les répertoires personnels de l'utilisateur, etc.

Il ne reste plus qu'à décider quels systèmes de fichiers il est conseillé d'isoler de l'arborescence de fichiers commune, et pourquoi le faire. La réponse à ces questions dépend beaucoup du système d'exploitation utilisé et, dans le cas de Linux, également de sa distribution. Néanmoins, les principes généraux de séparation des systèmes de fichiers peuvent être esquissés. Pourquoi faut-il rappeler l'opposition, d'une part, des répertoires immuables et mutables, d'autre part, des données facilement récupérables, difficiles à récupérer et pratiquement irrécupérables. Faisons cette tentative par rapport à un bureau d'utilisateur - dans le cas d'un serveur, les calculs seront très différents.

De toute évidence, le système de fichiers racine dans les répertoires /bin, /boot, /etc, /root, /sbin, contenant facilement récupérable à partir du support de distribution et des données pratiquement inchangées, doit se trouver sur une partition de disque isolée. Sous Linux, le répertoire /lib doit également être ajouté. D'un autre côté, lors de l'utilisation de GRUB comme chargeur de démarrage (quel que soit le système d'exploitation), il est recommandé de déplacer le répertoire / boot vers une partition séparée.

Dans les anciennes sources sur Linux, vous pouvez lire une autre raison d'allouer une partition pour le répertoire /boot, et au tout début du disque : en raison de l'impossibilité de charger le noyau avec Lilo à partir d'un numéro de cylindre supérieur à 1023. Dans versions modernes des chargeurs de démarrage, il n'y a pas de telles restrictions. Cependant, si vous créez une partition pour / boot, il est logique d'en faire la première sur le disque et de placer la partition de swap directement derrière : cela ajoutera cinq kopecks à la vitesse lors de l'échange.

Et encore une chose dans le domaine de l'histoire : l'exigence que les partitions racine et de démarrage soient par tous les moyens primaires a également été supprimée il y a longtemps. Et ces systèmes de fichiers peuvent parfaitement tenir sur des partitions logiques au sein d'une partition étendue.

Il est également clair que les branches mutables du système de fichiers - / var et / tmp - doivent être déplacées en dehors de la partition racine. De plus, ce dernier, comme cela a été dit maintes fois précédemment, est généralement conseillé de le placer sur le système de fichiers en RAM (tmpfs ou mfs). Dans le cas où le répertoire / var contient des sous-répertoires pour les systèmes de gestion de paquets de type port, comme / var / abs, / var / cache / pacman / src et / var / cache / pacman / pkg dans Archlinux, ils doivent également former leur propre fichier systèmes.

Maintenant le répertoire /usr, qui contient soit les composants du système de base (comme dans BSD) soit l'essentiel des applications utilisateur (comme dans la plupart des distributions Linux). Il contient des données facilement récupérables et, pour cause, devrait être pratiquement immuable, et donc, bien sûr, mérite d'être mis en évidence sur une section indépendante. De plus, il convient d'isoler de sa composition, d'une part, les sous-répertoires /usr/X11R6 et /usr/local, d'autre part, les sous-répertoires pour les systèmes de gestion de paquets de type port : /usr/ports, /usr/pkgsrc et /usr/pkg dans les systèmes BSD, /usr/portages sur Gentoo Linux, et ainsi de suite. De plus, les sous-répertoires pour placer les sources téléchargées depuis le réseau lors de la construction des ports doivent être séparés de ces derniers - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles et ainsi de suite.

Dans les systèmes BSD, en outre, il est judicieux de séparer les sous-répertoires /usr/src et /usr/obj du répertoire /usr, qui contiennent les sources des composants de base (y compris le noyau) et leurs produits intermédiaires de compilation, qui sont généré par les procédures make buildworld et make buildkernel. ...

Enfin, le répertoire /home, qui contient des données volatiles et souvent irrécupérables, doit être supprimé de la racine de la hiérarchie des fichiers sans faute. Et j'essaie toujours de le placer soit sur une tranche séparée (sous BSD) soit sur la partition primaire (sous Linux).

Le schéma de partitionnement du système de fichiers proposé peut sembler trop compliqué. Cependant, il garantit l'isolement des données facilement récupérables, difficiles à récupérer et non récupérables, ce qui facilite la réinstallation du système en cas d'urgence, et même la migration d'un système à l'autre.

Son avantage supplémentaire est que pour les branches individuelles de l'arborescence de fichiers, en fonction de la nature des données qui s'y trouvent, sous Linux, vous pouvez choisir un système de fichiers physiquement optimal. Par exemple, pour une partition sous /boot, cela n'a aucun sens d'utiliser autre chose que Ext2fs. Il est généralement recommandé de formater la partition racine avec un Ext3fs sécurisé et pourtant le plus compatible. Pour les répertoires contenant un grand nombre de petits fichiers, tels que /var/abs dans Archlinux, /usr/portages dans Gentoo, il est conseillé d'utiliser ReiserFS : après tout, la gestion habile des petits fichiers est son profil. Et dans le répertoire / home, où d'énormes fichiers multimédias peuvent apparaître (et qui est généralement très volumineux en soi), XFS peut venir au tribunal (bien que, comme le montrent les mesures, ReiserFS semble assez décent ici). De telles mesures peuvent améliorer à la fois la fiabilité du stockage des données et la vitesse des opérations sur les fichiers.

Les utilisateurs de systèmes d'exploitation BSD sont liés aux systèmes de fichiers de type FFS sans aucune alternative. Cependant, ils ont aussi une marge de manœuvre. Premièrement, en faisant varier la taille du bloc et le fragment des systèmes de fichiers individuels, ce qui contribue soit à la performance des opérations de disque, soit à économiser de l'espace disque. Et d'autre part, certaines branches de l'arborescence des fichiers (telles que /tmp ou /usr/obj, contrairement aux recommandations, peuvent être montées sans crainte dans un mode purement asynchrone, gagnant un ou deux pourcentages en performances.

Sujet : Systèmes d'exploitation.
Question : n° 8

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

Principes de construction du système d'exploitation :

1.) Principe de modularité- par module, on entend généralement un élément fonctionnellement complet du système, réalisé conformément aux interfaces intermodulaires admises. Par sa définition, un module suppose la possibilité de le remplacer facilement par un autre si les interfaces spécifiées sont disponibles. Dans une large mesure, la division du système en modules est déterminée par la méthode de conception du système d'exploitation utilisée (bottom-up ou vice versa).

Les modules privilégiés, ré-entrants et ré-entrants sont d'une importance particulière lors de la construction d'un système d'exploitation (le ré-autorisation est littéralement un ré-autorisation ; un terme spécial pour désigner la santé d'un programme ; la propriété d'un programme à s'exécuter correctement lorsqu'un un appel récursif (retourné) à partir d'une interruption se produit).

Le plus grand effet de l'utilisation de ce principe est réalisable dans le cas de l'extension simultanée de ce principe au système d'exploitation, aux programmes d'application et au matériel.

2.) Principe de sélectivité fonctionnelle- une certaine partie des modules importants est allouée dans l'OS, qui doit être constamment dans la RAM pour une organisation plus efficace du processus de calcul. Cette partie est appelée le noyau dans le système d'exploitation, car c'est la base du système. Lors de la formation de la composition du noyau, deux exigences contradictoires doivent être prises en compte. D'une part, les modules système les plus fréquemment utilisés doivent être inclus dans le noyau, d'autre part, le nombre de modules doit être tel que la quantité de mémoire occupée par le noyau ne soit pas trop importante. En plus des modules logiciels qui composent le noyau et sont situés en permanence dans la RAM, il peut y avoir de nombreux autres modules logiciels système appelés transit. Les modules de programme de transit ne sont chargés dans la RAM que lorsque cela est nécessaire et en l'absence d'espace libre, ils peuvent être remplacés par d'autres modules de transit.

3.) Principe de génération du système d'exploitation : L'essentiel du principe consiste à organiser (choisir) une telle méthode pour la présentation initiale du programme central de contrôle du système de l'OS (le noyau et les principaux composants en permanence en RAM), ce qui a permis de personnaliser cette partie de supervision du système en fonction sur la configuration spécifique d'un complexe informatique particulier et l'éventail des tâches à résoudre. Cette procédure est rarement effectuée avant une période de fonctionnement assez longue de l'OS. Le processus de génération est effectué à l'aide d'un programme générateur spécial et d'un langage d'entrée approprié pour ce programme, qui permet de décrire les capacités logicielles du système et la configuration de la machine. À la suite de la génération, la version complète du système d'exploitation est obtenue. La version du système d'exploitation générée est une collection d'ensembles système de modules et de données.

4.) Principe de redondance fonctionnelle : Ce principe prend en compte la possibilité de réaliser le même travail par des moyens différents. L'OS peut comprendre plusieurs types de moniteurs (modules de supervision qui contrôlent tel ou tel type de ressource), divers moyens d'organiser les communications entre processus informatiques. La présence de plusieurs types de moniteurs, plusieurs systèmes de gestion de fichiers permet aux utilisateurs d'adapter rapidement et le plus adéquatement le système d'exploitation à une configuration spécifique d'un système informatique, pour assurer le chargement le plus efficace du matériel lors de la résolution d'une classe spécifique de problèmes, pour obtenir le maximum performances lors de la résolution d'une classe donnée de problèmes.

5.) Principe de virtualisation : la construction de ressources virtuelles, leur distribution et leur utilisation sont actuellement utilisées dans presque tous les systèmes d'exploitation. Ce principe vous permet de représenter la structure du système sous la forme d'un ensemble spécifique d'ordonnanceurs de processus et d'allocateurs de ressources (moniteurs) et d'utiliser un seul schéma d'allocation de ressources centralisé.

La manifestation la plus naturelle et la plus complète du concept de virtualité est le concept machine virtuelle... La machine virtuelle fournie à l'utilisateur reproduit l'architecture d'une machine réelle, mais les éléments architecturaux de cette représentation présentent des caractéristiques nouvelles ou améliorées, qui, en règle générale, simplifient le travail avec le système. Les caractéristiques peuvent être arbitraires, mais le plus souvent les utilisateurs souhaitent disposer de leur propre machine « idéale » en termes de caractéristiques architecturales dans la composition suivante :

- mémoire virtuelle de volume pratiquement illimité, uniforme en termes de logique de fonctionnement.

- un nombre arbitraire de processeurs virtuels capables de travailler en parallèle et d'interagir en cours de fonctionnement.

- un nombre arbitraire de dispositifs virtuels externes capables de travailler avec la mémoire d'une machine virtuelle en parallèle ou séquentiellement, de manière asynchrone ou synchrone par rapport au fonctionnement de l'un ou l'autre processeur virtuel qui initie le fonctionnement de ces dispositifs.

L'un des aspects de la virtualisation est l'organisation de la capacité à exécuter dans un système d'exploitation donné des applications qui ont été développées pour d'autres systèmes d'exploitation. En d'autres termes, il s'agit d'organiser plusieurs environnements opérationnels.

6.) Le principe de l'indépendance des programmes vis-à-vis des périphériques externes : ce principe est maintenant mis en œuvre dans l'écrasante majorité des systèmes d'exploitation à usage général. Pour la première fois, ce principe a été implémenté de la manière la plus cohérente dans le système d'exploitation UNIX. Il est également implémenté dans la plupart des systèmes d'exploitation PC modernes. Ce principe réside dans le fait que la connexion des programmes avec des appareils spécifiques s'effectue non pas au niveau de la diffusion du programme, mais pendant la période de planification de son exécution. Par conséquent, la recompilation n'est pas requise lorsque le programme s'exécute avec un nouvel appareil sur lequel se trouvent les données.

7.) Principe de compatibilité : l'un des aspects de la compatibilité est la capacité du système d'exploitation à exécuter des programmes écrits pour un autre système d'exploitation ou pour des versions antérieures de ce système d'exploitation, ainsi que pour une autre plate-forme matérielle. Il faut séparer les questions compatibilité binaire et compatibilité des sources applications.

La compatibilité binaire est obtenue lorsque vous pouvez prendre un programme exécutable et l'exécuter sur un autre système d'exploitation. Cela nécessite une compatibilité au niveau des instructions du processeur, et une compatibilité au niveau des appels système, et même au niveau des appels de bibliothèque, s'ils sont liés dynamiquement.

La compatibilité des sources nécessite un traducteur approprié dans le logiciel système, ainsi qu'une compatibilité avec les bibliothèques et les appels système. Dans ce cas, il est nécessaire de recompiler les textes sources existants dans un nouveau module exécutable.

Il est beaucoup plus difficile d'obtenir une compatibilité binaire entre des processeurs basés sur des architectures différentes. Pour qu'un ordinateur exécute les programmes d'un autre (par exemple, il est souhaitable qu'un programme pour un PC tel qu'un IBM PC s'exécute sur un PC tel qu'un Apple Macintosh), cet ordinateur doit fonctionner avec des instructions machine qu'il ne comprendre. Dans un tel cas, le processeur 680x0 (ou PowerPC) doit exécuter le binaire destiné au processeur i80x86. Le processeur 80x86 possède son propre décodeur d'instructions, ses registres et son architecture interne. Le processeur 680x0 ne comprend pas le binaire 80x86, il doit donc sélectionner chaque commande, la décoder pour déterminer si

ce qu'il est censé faire, puis exécutez le sous-programme équivalent écrit pour 680 × 0.

L'un des moyens d'assurer la compatibilité des logiciels et des interfaces utilisateurs est la conformité aux normes POSIX, dont l'utilisation permet de créer des programmes de style UNIX, facilement transférables ultérieurement d'un système à un autre.

8.) Le principe d'ouverture et d'évolutivité : Un système d'exploitation ouvert est disponible pour analyse par les utilisateurs et les spécialistes du système qui maintiennent le système informatique. Un système d'exploitation extensible (modifiable, développé) permet non seulement d'utiliser les capacités de génération, mais également d'introduire de nouveaux modules dans sa structure, d'améliorer ceux qui existent déjà, etc. En d'autres termes, il devrait être possible d'effectuer facilement des ajouts et des modifications si nécessaire sans compromettre l'intégrité du système. L'approche client-serveur pour structurer le système d'exploitation à l'aide de la technologie micronucléaire offre d'excellentes opportunités d'expansion. Conformément à cette approche, le système d'exploitation est construit comme un ensemble de programmes de contrôle privilégiés et un ensemble de services non privilégiés (serveurs). La partie principale du système d'exploitation reste inchangée, et en même temps de nouveaux serveurs peuvent être ajoutés ou les anciens améliorés. Ce principe est parfois interprété comme extensibilité du système.

9.) Principe de mobilité : le système d'exploitation doit être relativement facile à transporter

Connectez-vous d'un type de processeur à un autre type de processeur et d'une plate-forme matérielle d'un type, qui comprend, avec le type de processeur et la manière d'organiser tout le matériel informatique (architecture du système informatique), à ​​un autre type de plate-forme matérielle. A noter que le principe de portabilité est très proche du principe de compatibilité, bien qu'il ne s'agisse pas de la même chose. Écrire un système d'exploitation portable, c'est comme écrire n'importe quel code portable, mais il y a quelques points à suivre. règles:

- la plupart des OS doivent être exécutés dans un langage disponible sur tous les systèmes vers lesquels il est prévu de le porter ultérieurement. Cela signifie tout d'abord que l'OS doit être écrit dans un langage de haut niveau, de préférence un langage standardisé, par exemple en C. Un programme écrit en assembleur n'est généralement pas portable.

- il est important de minimiser ou, si possible, d'exclure les parties du code qui interagissent directement avec le matériel. La dépendance au matériel peut prendre plusieurs formes. Certaines formes évidentes de dépendance incluent la manipulation directe de registres et d'autres matériels. Enfin, si le code dépendant du matériel ne peut pas être complètement exclu, alors il doit être isolé dans plusieurs modules bien localisés. Le code dépendant du matériel n'a pas besoin d'être distribué dans tout le système. Par exemple, vous pouvez masquer une structure dépendante du matériel dans un type de données abstrait programmable.

L'introduction des normes POSIX visait à assurer la portabilité du logiciel créé.

10.) Principe de sécurité informatique : Assurer la sécurité informatique est une caractéristique souhaitable pour tout système multi-utilisateurs. Les règles de sécurité définissent des propriétés telles que la protection des ressources d'un utilisateur contre les autres et la définition de quotas de ressources pour empêcher un utilisateur de s'emparer de toutes les ressources système, telles que la mémoire.

Assurer la protection des informations contre les accès non autorisés est une fonction obligatoire des systèmes d'exploitation de réseau.

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

QuoiPOSIX: une interface système indépendante de la plate-forme pour un environnement informatique POSIX (Portable Operating System Interface for Computer Environments) est une norme IEEE (Institute of Electrical and Electronics Engineers), qui décrit les interfaces système pour les systèmes d'exploitation ouverts, y compris les shells, les utilitaires et les boîtes à outils. De plus, POSIX standardise les tâches de sécurité, les tâches en temps réel, les processus d'administration, les fonctions réseau et le traitement des transactions. La norme est basée sur les systèmes UNIX, mais peut également être implémentée dans d'autres systèmes d'exploitation. POSIX est né d'une tentative de l'organisation de renommée mondiale IEEE de promouvoir la portabilité des applications dans les environnements UNIX en développant une norme abstraite indépendante de la plate-forme. Par exemple, le système d'exploitation temps réel bien connu QNX est conforme aux spécifications de cette norme.

Cette norme décrit en détail le système de mémoire virtuelle VMS (Virtual Memory System), MPE (Multi-Process Executing) multitâche et CTOS (An Operating System produit Convergent Technology...). Ainsi, POSIX est en fait un ensemble de normes appelé POSIX.I –POSIX.12. Il convient également de noter que POSIX.1 suppose C comme langage principal.

Langage de description des fonctions du système API.

Ainsi, les programmes écrits conformément à ces normes fonctionneront de manière identique sur tous les systèmes compatibles POSIX. Cependant, dans certains cas, la norme n'a qu'un caractère consultatif. Certaines des normes sont décrites de manière très stricte, tandis que l'autre partie ne révèle que superficiellement les exigences de base.

Les implémentations du système d'exploitation de l'API POSIX sont différentes. Si la grande majorité des systèmes UNIX sont initialement conformes aux spécifications de la norme IEEE 1003.1-1990, alors WinAPI n'est pas compatible POSIX. Cependant, pour prendre en charge cette norme dans le système d'exploitation MS Windows NT, un module de prise en charge API POSIX spécial a été introduit qui fonctionne au niveau de privilège des processus utilisateur.

Ce module permet la conversion et le transfert des appels du programme utilisateur vers le noyau système et inversement, en travaillant avec le noyau via l'API Win. D'autres applications construites à l'aide de WinAPI peuvent transmettre des informations aux applications POSIX via des mécanismes de flux d'E/S standard (stdin, stdout).

Aucun article lié...

POSIX (Portable Operating System Interface for Computer Environments) est une norme IEEE (Institute of Electrical and Electronics Engineers) qui décrit les inter-systèmes.

"Dans ce contexte, les commandes système doivent être comprises comme un certain ensemble de programmes qui vous permettent de contrôler les processus de calcul, par exemple, pstat, kill, dir, etc.

Interface POSIX___________________________________________________ 305

faces pour les systèmes d'exploitation open source, y compris les shells, les utilitaires et les boîtes à outils. De plus, POSIX a standardisé les tâches de sécurité, les tâches en temps réel, les processus d'administration, les fonctions de mise en réseau et le traitement des transactions. La norme est basée sur les systèmes UNIX, mais peut également être implémentée sur d'autres systèmes d'exploitation.

L'interface POSIX a commencé comme une tentative de l'IEEE pour promouvoir la portabilité des applications dans les environnements UNIX en développant une norme abstraite indépendante de la plate-forme. Cependant, POSIX n'est pas limité aux systèmes UNIX ; Il existe diverses implémentations de cette norme sur des systèmes qui répondent aux exigences de la norme IEEE 1003.1-1990 (POSIX. 1). Par exemple, le système d'exploitation temps réel bien connu QNX est conforme aux spécifications de cette norme, ce qui facilite le portage des applications sur ce système, mais UNIX n'est sous aucune forme, car son architecture utilise des principes complètement différents.

Cette norme détaille la technologie Virtual Memory System (VMS), Multiprocess Executing (MPE) et Transferring Operating Systems (CTOS). Donc, POSIX est en fait de nombreuses normes POSIX. 1-POSIX. 12. Tableau 9.1 énumère les principaux domaines décrits par ces normes. Il convient également de noter que POSIX. 1, le langage principal pour décrire les fonctions de l'API système est supposé être le langage C.

Tableau 9.1. La famille de normes POSIX

Brève description de la norme ISO

POSIX.0 Aucun Introduction à la norme des systèmes ouverts. Ce document

pas une pure norme, mais une recommandation et un bref aperçu des technologies

POSIX.1 Oui API système (C)

POSIX.2 Pas de skins et d'utilitaires (approuvé IEEE)

POSIX.3 Aucun test ni vérification

POSIX.4 Aucun Tâches et threads en temps réel

POSIX.5 Oui Utilisation du langage ADA le cas échéant

à la norme POSIX. 1

POSIX.6 Pas de sécurité du système

POSIX.7 Pas d'administration système

POSIX.8 Pas de réseau, accès aux fichiers transparent, résumé

interfaces réseau indépendantes du protocole physique, appels RPC, communication système avec des applications dépendantes du protocole

POSIX.9 Oui Utilisation du langage Fortran, applicable

à la norme POSIX. 1

POSIX. 10 Pas de profil d'environnement d'application de super-informatique (AEP)

POSIX. 11 Pas de traitement des transactions AEP

POSIX. 12 Aucune interface utilisateur graphique (GUI)

306________________________________ Chapitre 9. Architecture du système d'exploitation

Ainsi, les programmes écrits conformément à ces normes fonctionneront de manière identique sur tous les systèmes compatibles POSIX. Cependant, les normes n'ont en partie qu'un caractère consultatif. Certaines des normes sont décrites de manière très stricte, tandis que l'autre partie ne révèle que superficiellement les exigences de base. Souvent, les systèmes logiciels sont prétendus conformes à POSIX, bien qu'ils ne puissent pas être appelés ainsi. Les raisons résident dans l'approche formelle de la mise en œuvre de l'interface POSIX dans divers systèmes d'exploitation. En figue. 9.1 montre un schéma d'implémentation typique d'une application strictement conforme à POSIX.

Riz. 9.1. Schéma d'implémentation d'une application strictement conforme à la norme POSIX

La figure montre que le programme utilise uniquement des bibliothèques POSIX pour interagir avec le système d'exploitation. 1 et la bibliothèque standard C RTL, dans laquelle seules 110 fonctions différentes peuvent être utilisées, également décrites par le standard POSIX. 1.

Malheureusement, assez souvent, afin d'augmenter les performances d'un sous-système particulier ou d'introduire des technologies propriétaires qui limitent la portée de l'application à l'environnement d'exploitation correspondant, d'autres fonctions non conformes à la norme POSIX sont utilisées en programmation.

Les implémentations du système d'exploitation de la norme POSIX sont différentes. Si la grande majorité des systèmes UNIX sont initialement conformes aux spécifications de la norme IEEE 1003.1-1990, alors WinAPI n'est pas compatible POSIX. Cependant, pour le prendre en charge dans le système d'exploitation Windows NT, un module API spécial a été introduit pour prendre en charge la norme POSIX, fonctionnant au niveau de privilège des processus utilisateur. Ce module permet la conversion et le transfert des appels d'un programme utilisateur vers le noyau système et inversement, en travaillant avec le noyau via WinAPI. D'autres applications écrites à l'aide de WinAPI peuvent transmettre des informations POSIX aux applications via les flux d'E/S standard stdin et stdout.

Exemples de programmation pour différentes API____________________ 307

Exemples de programmation pour différentes API

Pour démontrer clairement les différences fondamentales entre les API des systèmes d'exploitation modernes les plus populaires pour ordinateurs personnels, considérons un exemple simple dans lequel vous devez compter le nombre d'espaces dans les fichiers texte dont les noms doivent être spécifiés sur la ligne de commande. Considérons deux versions du programme : pour Windows (utilisant WinAPI) et pour Linux (POSIX API).

Puisque nous sommes intéressés à travailler avec des tâches parallèles, laissez lors de l'exécution d'un programme pour chacun des fichiers répertoriés sur la ligne de commande, créer son propre processus ou thread d'exécution (tâche), qui, en parallèle avec d'autres processus (threads), effectue travailler sur le comptage des espaces dans son « propre » fichier. Le résultat du programme sera une liste de fichiers avec le nombre compté d'espaces pour chacun.

Vous devez porter une attention particulière au fait que la mise en œuvre des programmes pour résoudre ce problème ci-dessous ne sont pas les seules possibles. Les deux systèmes d'exploitation considérés ont des méthodes différentes pour travailler avec le système de fichiers et gérer les processus. Dans ce cas, une seule variante est considérée, mais la plus typique pour l'interface API correspondante.

Pour faciliter la comparaison de ce programme (extrait 9.1) et du programme suivant (extrait 9.2), et considérant également que la tâche ne nécessite pas d'interface de fenêtre pour sa solution, seuls les appels d'API qui n'affectent pas l'interface graphique sont utilisés dans le texte. Bien sûr, de nos jours, rarement une application n'utilise les capacités de l'interface graphique, mais dans notre cas, vous pouvez immédiatement voir la différence dans l'organisation du fonctionnement en parallèle des calculs en cours de démarrage.

POSIX et RV OS : une tentative de systématisation

Sergueï Zolotarev, Nikolaï Gorbounov

Le but de cet article est une tentative de clarifier l'histoire du développement de la norme POSIX appliquée aux systèmes d'exploitation en temps réel (RT OS).

En guise d'introduction : pourquoi la standardisation des interfaces de programmation est-elle nécessaire ?

L'une des caractéristiques les plus importantes de la norme POSIX est qu'elle définit une "interface de programmation standardisée" à laquelle les développeurs de systèmes logiciels et matériels complexes doivent adhérer. Les créateurs de ces systèmes sont contraints de faire face à des exigences telles que des délais de mise sur le marché serrés (en raison d'une concurrence féroce), la minimisation des coûts et l'accélération du retour sur investissement. Dans le même temps, la part du lion des coûts dus au ralentissement du processus de développement est associée au fait que les programmeurs doivent « réinventer la roue », sans cesse en implémentant des fonctionnalités disponibles depuis longtemps. Mais cela aurait pu être évité en :

• réutilisation du code des projets passés et parallèles ;
• le portage de code à partir d'autres systèmes d'exploitation ;
• attirer des développeurs d'autres projets (y compris en utilisant d'autres systèmes d'exploitation).

Tout cela est possible grâce à l'utilisation d'un OS avec une API standardisée. De plus, si dans le premier cas, il suffit à une organisation d'avoir un certain standard interne (ce qui est particulièrement typique pour les systèmes d'exploitation propriétaires), alors les deux seconds cas nécessitent simplement la présence de standards généralement acceptés - par exemple, POSIX.

Ainsi, en utilisant un système d'exploitation compatible POSIX comme plate-forme pour ses projets, le développeur a la possibilité de transférer le code fini au niveau du texte source à la fois de ses projets passés ou parallèles et de projets de tiers. Cela réduit non seulement considérablement le temps de développement du logiciel, mais améliore également sa qualité, car le code testé contient toujours moins d'erreurs.

Qui est qui dans le développement POSIX

Et nous ne commencerons pas par le standard POSIX lui-même, mais par l'ordonnancement du rôle des organisations impliquées dans le travail sur celui-ci.

Le premier participant est IEEE(Institut des ingénieurs électriciens et électroniciens, Institut des ingénieurs électriciens et électroniciens), une association publique de professionnels à but non lucratif. L'IEEE remonte à 1884 (officiellement - à partir de 1963), rassemble 380 000 membres individuels de 150 pays, publie une troisième partie de la littérature technique liée à l'utilisation des ordinateurs, du contrôle, de l'électricité et des technologies de l'information, ainsi que plus de 100 revues. populaire parmi les professionnels; en outre, l'association organise plus de 300 grandes conférences par an. L'IEEE a participé au développement de plus de 900 normes existantes (www.ieee.ru/ieee.htm). Aujourd'hui, cet institut est engagé dans la préparation, la coordination, l'approbation, la publication de normes, mais en raison de son statut officiel, il n'a pas le pouvoir d'adopter de tels documents en tant que normes internationales ou nationales. Par conséquent, le terme « norme » dans la compréhension de l'IEEE doit plutôt être compris comme « spécification », ce qui est plus cohérent avec le statut des documents acceptés par l'association. Conformément à l'IEEE, il participe aux programmes d'un certain nombre d'organisations internationales et régionales - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standartization) et aux programmes, par exemple, dans le programme d'une telle organisation comme l'ANSI.

L'IEEE comprend le PASC (Portable Application Standards Committee), un comité d'association qui développe la famille de normes POSIX (www.pasc.org/). Le PASC était auparavant connu sous le nom de Comité technique des systèmes d'exploitation.

Le deuxième participant au travail - ANSI(American National Standards Institute, American National Standards Institute) est une organisation privée à but non lucratif qui administre et coordonne les activités de normalisation aux États-Unis. Il n'emploie que 75 personnes, mais les membres de l'ANSI comprennent plus de 1 000 entreprises, organisations, agences gouvernementales et institutions (www.ansi.org). L'ANSI représente les États-Unis dans deux grands organismes internationaux de normalisation, l'ISO et la CEI.

Troisième participant - ISO(Organisation internationale de normalisation). Il a été créé en 1946 par décision du Comité de coordination des normes et de l'Assemblée générale des Nations Unies et a officiellement commencé ses travaux le 23 février 1947 (www.iso.org). L'ISO est un réseau d'instituts nationaux de normalisation de 146 pays (un pays - un membre de l'ISO) avec un secrétariat central à Genève (Suisse). Les normes ISO sont élaborées au sein de comités techniques, dont le premier produit est le projet de norme internationale (DIS), qui, après plusieurs approbations, devient le projet final de norme internationale (FDIS). Après cela, la question de l'approbation de ce document est mise aux voix ; en cas de succès, il devient une norme internationale.

Et enfin - CEI(Commission électrotechnique internationale, Commission électrotechnique internationale - CEI), fondée en 1906, la CEI prépare et publie des normes internationales pour toutes les technologies électriques, électroniques et connexes (www.iec.ch/). Au 1er novembre 2004, les comités nationaux de 64 pays étaient des membres actifs de cette commission. La CEI publie également des recommandations, qui sont publiées en anglais et en français et ont le statut de normes internationales. Sur leur base, des normes régionales et nationales sont élaborées. Les comités techniques (TC) sont responsables de la préparation de normes dans divers domaines d'activités de la CEI, auxquelles participent les comités nationaux intéressés par les activités d'un TC particulier.

La CEI est une organisation clé dans la préparation des normes internationales des technologies de l'information. Dans ce domaine, il existe un comité technique mixte sur les technologies de l'information - JTC 1, formé en 1987 conformément à un accord entre la CEI et l'ISO. JTC1 dispose de 17 sous-comités supervisant tout, des logiciels aux langages de programmation, en passant par l'infographie et l'édition d'images, l'interconnexion des équipements et les pratiques de sécurité.

La préparation de nouvelles normes CEI comprend plusieurs étapes (étape préliminaire, étape de proposition, étape préparatoire, étape du comité technique, étape de demande, étape d'approbation, publication). Si le document CEI est destiné à devenir uniquement une spécification technique et non une norme internationale, une version révisée du document est envoyée au siège pour publication. La version finale de la norme internationale (FDIS) prendra quatre mois. S'il est approuvé par tous les membres du comité technique, il est envoyé au bureau central pour publication sans l'étape d'approbation du FDIS. Ensuite, le FDIS passe devant les comités nationaux, qui doivent l'approuver dans un délai de deux mois. Le FDIS est considéré comme approuvé si plus des deux tiers des comités nationaux ont voté en sa faveur et que le nombre de votes négatifs ne dépasse pas 25 %. Si le document n'est pas approuvé, il est envoyé pour révision aux comités techniques et sous-comités. La norme doit être publiée au plus tard deux mois après l'approbation du FDIS.

Plusieurs autres organisations sont impliquées dans le développement et l'adoption des normes POSIX.

Ouvrir le groupe est une organisation internationale de normalisation logicielle, qui rassemble près de 200 fabricants et communautés d'utilisateurs travaillant dans le domaine des technologies de l'information (www.opengroup.org/). L'Open Group a été formé en 1995 par la fusion de ses deux prédécesseurs : X/Open et l'Open Software Foundation (OSF). The Open Group est spécialisé dans le développement de méthodologies de certification de logiciels et de tests de conformité. En particulier, l'Open Group fournit des certifications pour des domaines tels que la plate-forme COE, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP), et enfin le Famille de normes POSIX (www.opengroup.org/certification/).

Groupe de révision des normes communes d'Austin (CSRG)- un groupe de travail technique conjoint formé en 2002 par l'ISO, la CEI et l'Open Group pour créer et maintenir les dernières versions de la norme 1003.1, qui sera constituée sur la base des normes ISO/IEC 9945-1-1996, ISO/IEC 9945 -2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 et spécification UNIX unique (www.opengroup.org/press/14nov02.htm).

Institut national des normes et de la technologie (NIST)- une agence fédérale au sein de la Technology Administration du Département du Commerce (www.nist.gov/public_affairs/general2.htm), fondée aux États-Unis en 1901. La mission du NIST est de développer et de promouvoir des normes et des technologies pour améliorer la qualité des produits. Le NIST comprend un laboratoire de technologie de l'information (ITL), dont l'un des résultats est Federal Information Processing Standards (FIPS, www.opengroup.org/testing/fips/general_info.html). Le NIST / ITL a proposé une première série de tests pour la certification POSIX sous FIPS PUB 151-1 1990 en 1991.

Qu'est-ce que POSIX ?

Formellement le terme POSIX proposé par Richard Stallman comme abréviation de P ortable ô opérer S interface système pour l'ONU IX(interface de système d'exploitation portable pour Unix). POSIX a été développé pour les systèmes d'exploitation de type UNIX (leurs premières versions remontent au début des années 1970) dans le but de fournir la portabilité des sources aux applications.

La description initiale de l'interface a été publiée en 1986, lorsqu'elle s'appelait IEEE-IX (version IEEE d'UNIX). Cependant, le nom a rapidement changé, devenant POSIX, et déjà dans la publication suivante (en 1986) cette nouvelle version a été utilisée Pendant un certain temps, POSIX a été compris comme une référence (ou synonyme) à un groupe de documents connexes IEEE 1003.1-1988 et des parties de l'ISO / IEC 9945, et comme une norme internationale complète et approuvée ISO / IEC 9945.1: 1990 POSIX a été adoptée en 1990. Les spécifications POSIX définissent un mécanisme standard d'interaction entre un programme d'application et le système d'exploitation et comprennent actuellement plus de 30 normes sous les auspices de l'IEEE, de l'ISO, de la CEI et de l'ANSI.

Tout au long de son histoire, POSIX a parcouru un long chemin, la notation des spécifications, leur contenu spécifique, les procédures et la logistique de leur vérification ont changé à plusieurs reprises. Depuis lors, plusieurs éditions de la norme POSIX ont été publiées dans le cadre de diverses organisations internationales.

L'histoire du développement de la norme POSIX

La première version de la spécification IEEE Std 1003.1 a été publiée en 1988. Par la suite, de nombreuses éditions de IEEE Std 1003.1 ont été adoptées en tant que normes internationales.

Étapes de développement POSIX :

1990 année

L'édition, publiée en 1988, a été révisée et est devenue la base de nouvelles révisions et ajouts. Il a été approuvé en tant que norme internationale ISO / IEC 9945-1: 1990.

1993 année

L'édition 1003.1b-1993 est publiée.

année 1996

Des modifications ont été apportées à IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 et 1003.1i-1995, mais la majeure partie du document reste inchangée. En 1996, la révision de la norme IEEE Std 1003.1 a également été approuvée en tant que norme internationale ISO / IEC 9945-1 : 1996.

année 1998

La première norme pour "temps réel" est apparue - IEEE Std 1003.13-1998. Il s'agit d'une extension du standard POSIX pour les applications embarquées temps réel.

année 1999

Il a été décidé d'apporter des modifications importantes au texte principal de la norme pour la première fois au cours des 10 dernières années, y compris la fusion avec la norme 1003.2 (Shell et services publics), car à ce moment-là, il s'agissait de normes distinctes. Le PASC a décidé de finaliser les modifications du texte de base après l'achèvement des normes IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q et 1003.2b.

2004 r.

La révision la plus récente de 1003.1 a été publiée le 30 avril et publiée sous les auspices de l'Austin Common Standards Revision Group. Il est modifié pour l'édition 2001 de la norme. Formellement, l'édition 2004 est connue sous le nom de IEEE Std 1003.1, 2004 Edition, The Open Group Technical Standard Base Specifications, Issue 6 et comprend IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 et IEEE Std 1003.1-2001 / Cor 2-2004.

Les normes POSIX les plus importantes pour le système d'exploitation RT

Pour les systèmes d'exploitation en temps réel, sept spécifications de la norme sont les plus importantes (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), mais seulement trois ont été largement prises en charge dans les systèmes d'exploitation commerciaux :

• 1003.1a (définition du système d'exploitation) définit les principales interfaces du système d'exploitation, le contrôle des tâches, les signaux, les fonctions du système de fichiers et fonctionne avec les périphériques, les groupes d'utilisateurs, les pipelines, les tampons FIFO ;
• 1003.1b (Extensions en temps réel) décrit les extensions temps réel telles que les signaux temps réel, l'ordonnancement prioritaire, les temporisateurs, les E/S synchrones et asynchrones, les sémaphores, la mémoire partagée, les messages. Initialement (avant 1993), cette norme était appelée POSIX.4.
• 1003.1c (fils) définit les fonctions de support de thread - contrôle de thread, attributs de thread, mutex, dispatching. Initialement désigné comme POSIX.4a.

En plus de ces normes, les normes suivantes sont importantes pour le système d'exploitation RT, qui ont été mises en œuvre dans le cadre des travaux sur le projet Std 1003.1-2001 :

• IEEE 1003.1d-1999. Extensions en temps réel supplémentaires. Initialement désigné comme POSIX.4b ;
• IEEE 1003.1j-2000. Extensions en temps réel améliorées (avancées);
• IEEE 1003.1q-2000. Tracé.

Procédure de certification

Pour être conforme à POSIX, un système d'exploitation doit être certifié par rapport à la suite de tests appropriée. Depuis l'introduction de POSIX, la suite de tests a subi des changements formels et de facto.

En 1991, le NIST a développé un programme de test POSIX sous FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Cette option de test était basée sur la norme IEEE 1003.3 "Standard for Test Methods for Measuring Conformance to POSIX" Draft 10, 3 mai 1989. En 1993, le NIST a terminé le programme de test POSIX pour FIPS 151-1 et a commencé le programme pour FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 a adapté « Information Technology - Portable Operating System Interface (POSIX) - Part 1 : System Application Program Interface (API) », qui est une norme ISO / IEC 9945-1: 1990. Les suites de tests pour FIPS 151-2 étaient basées sur la norme IEEE 2003.1-1992 "Standard for Test Methods for Measuring Conformance to POSIX".

Le NIST distingue deux méthodologies de certification : l'auto-certification et la certification par des laboratoires d'essais accrédités IEEE (Accredited POSIX Testing Laboratories - APTL). Dans le premier cas, l'entreprise effectue elle-même les tests, mais selon un plan approuvé par le NIST. Dans le second cas, les tests sont effectués par un laboratoire indépendant utilisant des suites de tests automatisés. Au total, deux laboratoires APTL ont été accrédités : Mindcraft (www.mindcraft.com) et Perennial (www.peren.com).

En 1997, le NIST/ITL annonçait son intention de mettre fin à la certification FIPS 151-2 à la fin de cette année (officiellement le 31 décembre 1997), tandis que l'Open Group annonçait qu'il allait prendre le relais à partir du 1er octobre de la même année. service de certification d'un an conformément à FIPS 151-2, basé sur le programme NIST / ITL. Les mêmes fonctions ont été reprises par l'IEEE Standards Association (IEEE-SA) depuis le 1er janvier 1998, et également basées sur FIPS 151-2.

En 2003, l'IEEE-SA et l'Open Group ont annoncé un nouveau programme commun pour certifier les dernières versions de POSIX commençant par IEEE 1003.1 ™ 2001. L'Open Group dispose désormais de plusieurs suites de tests qui couvrent IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 , IEEE Std 1003.1-2003 et IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Un produit est considéré comme certifié POSIX s'il a passé avec succès la procédure de certification complète, selon les résultats des tests, il répond à toutes les exigences et est inscrit dans le registre officiel des produits certifiés.

Les suites de tests comprennent :

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - un ensemble de tests de conformité pour les interfaces système IEEE Std 1003.1-1990 ;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - un ensemble de tests de conformité pour le profil IEEE Std 1003.13-1998 PSE54 (polyvalent en temps réel) ;
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - un ensemble de tests de conformité pour les interfaces système IEEE Std 1003.1-2003 (pièces obligatoires uniquement) ;
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) est un ensemble de tests de conformité pour IEEE Std 1003.1-2003 (shell et utilitaires - pièces requises uniquement).

De plus, l'Open Group a développé des références pour les standards POSIX Realtime et le profil de standards POSIX embarqués. La suite de tests en temps réel POSIX (www.opengroup.org/testing/testsuites/realtime.html) comprend les tests suivants :

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Extension temps réel et IEEE POSIX 1003.1, édition 2003 ;
• Extension IEEE Std POSIX 1003.1c-1995 Threads (pthreads) et édition IEEE POSIX 1003.1,2003 ;
• Extension temps réel supplémentaire IEEE POSIX 1003.1d-1999 et édition IEEE POSIX 1003.1,2003 ;
• Extension temps réel avancée IEEE POSIX 1003.1j-2000 et édition IEEE POSIX 1003.1,2003 ;
• Trace IEEE POSIX 1003.1q-2000 et édition IEEE POSIX 1003.1,2003 et édition IEEE POSIX 1003.1,2003 ;

La suite de tests de profils de normes POSIX intégrés (www.opengroup.org/testing/testsuites/embedded.html) comprend les tests suivants :

• IEEE POSIX 1003.1-1990 (5310 tests);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Extension temps réel (1430 tests) ;
• Extension IEEE Std POSIX 1003.1c-1995 Threads (pthreads) (1232 tests);
• IEEE POSIX 1003.13-1998 Profil 52.

Un peu de confusion dans la terminologie

En ce qui concerne le groupe de normes POSIX en anglais, non pas un, mais jusqu'à trois termes sont souvent utilisés. Malheureusement, ils ont un sens similaire et sont souvent traduits de la même manière, ce qui introduit une certaine confusion. Ces termes sont les suivants :

• compatibilité (littéralement - "compatibilité");
• conformité (littéralement - « conformité »);
• conformité (littéralement - "cohérence").

Le premier terme appliqué à POSIX n'est pas formellement défini. La seconde signifie que l'organisation - le fabricant du produit logiciel déclare indépendamment que ce produit (en tout ou en partie) est conforme aux normes NIST-PCTS répertoriées. Le troisième terme signifie que le produit logiciel a passé avec succès le système de test établi soit avec l'aide d'un laboratoire accrédité, soit au sein de l'Open Group et il existe une preuve documentaire de cela (la soi-disant déclaration de conformité). Plus loin dans le texte de l'article, les originaux des termes seront cités partout afin de lever l'ambiguïté.

Certifié OS RV

Si vous respectez les règles strictes exigeant que les données d'un RT OS certifié soient publiées dans le registre officiel et que les tests soient effectués au niveau de la conformité, il n'y a actuellement que deux RT OS certifiés (les données sont données par ordre chronologique) :

LynxOS v.3(un produit de Lynx Real-Time Systems, maintenant appelé LynuxWorks, Inc., www.lynuxworks.com) est conçu pour développer des logiciels pour les systèmes embarqués fonctionnant en temps réel dur, les fabricants d'équipements OEM et de télécommunications, en particulier les fabricants de systèmes embarqués pour les applications militaires... Le développement peut être effectué à la fois sur le système cible lui-même (auto-hébergé) et sur l'ordinateur instrumental (hôte), le logiciel fini est conçu pour fonctionner sur le système cible (cible). LynxOS v.3 est certifié conforme POSIX sur les plates-formes Intel et PowerPC. Des informations à ce sujet sont disponibles sur le site Web de l'IEEE à l'adresse http://standards.ieee.org/regauth/posix/posix2.html. LynxOS est certifié POSIX 1003.1-1996 par Mindcraft, un laboratoire de test POSIX accrédité IEEE POSIX sur la suite de tests de conformité NIST FIPS 151-2. Numéro du document de certification : Fichier de référence : IP-2LYX002, Fichier de référence : IP-2LYX001.

INTÉGRITÉ v.5(un produit de Green Hills Software, www.ghs.com) est certifié conforme à POSIX 1003.1-2003, System Interfaces for PowerPC architecture en juillet 2004 (http://get.posixcertified.ieee.org/select_product.tpl). Suite de tests VSX-PCTS 2003.

POSIX et le système d'exploitation QNX

QNX v.4.20 (développé par QNX Software Systems, www.qnx.com) est certifié conforme POSIX 1003.1-1988 pour la plate-forme Intel par DataFocus Incorporated. Tests effectués le 13 septembre 1993 et ​​publiés le 1er novembre 1993. NIST PCTS 151-1 Test Suite, Version 1.1.

QNX Neutrino (version 6.3) est conforme aux normes de la famille POSIX suivantes (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, le créateur de QNX Neutrino, prévoit également la conformité de QNX Neutrino à certaines de ces normes ; les travaux sont prévus pour 2005 (www.qnx.com/news/pr_959_1.html).

Littérature

1. Manuel d'utilisation de l'Association de normalisation IEEE. IEEE, octobre 2004.
2. Kevin M. Obeland. POSIX en temps réel, programmation de systèmes embarqués, 2001.
3. Norme IEEE / ANSI 1003.1 : Technologie de l'information - (POSIX) - Partie 1 : Application système : Interface de programme (API).
4. Gallmeister, B.O. Programmation pour le monde réel, POSIX.4 Sébastopol, Californie : O'Reilly & Associates, 1995.
5. Institut national des normes et de la technologie, PCTS : 151-2, POSIX Test Suite.
6. POSIX : Certifié par IEEE et The Open Group. Politique certifiée. The Open Group, 21 octobre 2003, Révision 1.1.