Il corso prende in esame lo standard per l'interfaccia del sistema operativo mobile (POSIX), nonché tecniche e metodi per la programmazione di applicazioni basate su questo standard, illustrate da numerosi esempi. Vengono toccate le questioni di programmazione di sistemi multiprocesso, interazione di applicazioni nell'ambito di configurazioni distribuite. Fornire mobilità (portabilità, portabilità) Software(PO) - un compito di eccezionale importanza e complessità; Al giorno d'oggi, questa circostanza difficilmente necessita di ampie giustificazioni.Uno dei modi generalmente accettati per aumentare la mobilità del software è quello di standardizzare l'ambiente applicativo: interfacce software fornite, utilità, ecc. A livello di servizi di sistema, tale ambiente è descritto dallo standard POSIX (Portable Operating System Interface); il nome è stato suggerito da un noto specialista, fondatore della Free Software Foundation Richard Stallman.

Il corso ne prende in esame la versione più moderna dell'edizione 2003, che può essere definita un "triplo standard", ovvero: lo standard IEEE Std 1003.1, lo standard tecnico di Open Group e, per noi cosa più importante, lo standard internazionale ISO/IEC 9945 standard di questo corso riguarda la comprensione delle tecniche e dei metodi di utilizzo di utilità e funzioni standardizzate. L'obiettivo non era quello di raccontare nuovamente lo standard, evidenziando tutte le sottigliezze dell'implementazione del sistema operativo, tutti i possibili codici di errore, ecc. La cosa principale, a nostro avviso, è sentire lo spirito dello standard, imparare a utilizzare le possibilità insite in esso in modo mobile. Supponendo che il lettore sia fluente in C, non abbiamo considerato né la sua sintassi né le funzioni di libreria dei libri di testo. Per quanto riguarda il linguaggio di comando standard e il suo interprete, questo argomento è descritto in dettaglio, sebbene molti programmatori praticanti preferiscano utilizzare altri interpreti. Un posto significativo - sia in termini di volume che di ruolo - è dato agli esempi di programmi. Molte disposizioni della norma (relative, ad esempio, alla gestione delle situazioni di errore) sono riportate non nel testo principale, ma negli esempi corrispondenti, che, se possibile, sono stati compilati ed eseguiti su più piattaforme hardware e software, ad una laurea o altro che dichiara di essere conforme allo standard POSIX. Tuttavia, le sviste sono certamente possibili. Saremo grati per tutti i commenti e suggerimenti relativi sia al corso nel suo insieme che a singoli esempi di programmi.

La storia della creazione e lo stato attuale dello standard POSIX.

Garantire la mobilità (portabilità, portabilità) del software (SW) è un compito di eccezionale importanza e complessità; nel nostro tempo, questa circostanza non ha bisogno di ampie giustificazioni. Uno dei modi generalmente accettati per aumentare la portabilità del software è standardizzare l'ambiente dell'applicazione: API fornite, utilità, ecc. A livello di servizi di sistema, tale ambiente è descritto dallo standard POSIX (Portable Operating System Interface); il nome è stato suggerito dal noto esperto, fondatore della Free Software Foundation, Richard Stallman.

Pagina del titolo.
Produzione.
Lezione 1. Concetti e idee di base dello standard POSIX.
Lezione 2. Il linguaggio della shell.
Lezione 3. Utilità e funzioni al servizio del concetto di "utente".
Lezione 4. Organizzazione del file system.
Lezione 5. Input/output di file.
Lezione 6. Strumenti per il trattamento dei dati strutturati.
Lezione 7. Processi.
Lezione 8. Mezzi di comunicazione tra processi.
Lezione 9. Interfaccia terminale comune.
Lezione 10. Interrogazione delle caratteristiche dell'ospite e loro utilizzo nelle applicazioni.
Lezione 11. Strutture di rete.
Lezione 12. Tempo e lavoro con lui.
Lezione 13. Ambiente linguistico e culturale.
Lezione 14. Conclusione.
Bibliografia.

Download gratuito e-book in un formato conveniente, guarda e leggi:
Scarica il libro Programmazione nello standard POSIX, parte 1, Galatenko V.A., 2016 - fileskachat.com, download veloce e gratuito.

POSIX e RV OS: un tentativo di sistematizzazione

Sergey Zolotarev, Nikolay Gorbunov

Lo scopo di questo articolo è un tentativo di fare chiarezza nella storia dello sviluppo dello standard POSIX applicato ai sistemi operativi in ​​tempo reale (RT OS).

Come introduzione: perché è necessaria la standardizzazione dell'interfaccia software?

Una delle caratteristiche più importanti dello standard POSIX è che definisce una "interfaccia di programmazione standardizzata" a cui devono aderire gli sviluppatori di sistemi software e hardware complessi. I creatori di questi sistemi sono costretti a far fronte a requisiti quali il time-to-market ristretto (a causa della forte concorrenza), la riduzione al minimo dei costi e l'accelerazione del ritorno sull'investimento. Allo stesso tempo, la parte del leone dei costi dovuti al rallentamento del processo di sviluppo è dovuta al fatto che i programmatori devono "reinventare la ruota", implementando più e più volte funzionalità disponibili da molto tempo. Ma questo avrebbe potuto essere evitato da:

• riutilizzo di codice da progetti passati e paralleli;
• porting di codice da altri sistemi operativi;
• attrarre sviluppatori da altri progetti (compresi quelli che utilizzano altri sistemi operativi).

Tutto questo è possibile grazie all'utilizzo di un sistema operativo con un'API standardizzata. Inoltre, se nel primo caso è sufficiente che un'organizzazione abbia un determinato standard interno (che è particolarmente tipico per i sistemi operativi proprietari), i secondi due casi richiedono solo la presenza di standard generalmente accettati, ad esempio POSIX.

Pertanto, utilizzando un sistema operativo compatibile con POSIX come piattaforma per i suoi progetti, lo sviluppatore ha l'opportunità di trasferire il codice finito a livello di codice sorgente sia dai suoi progetti passati o paralleli, sia da progetti di terze parti. Ciò non solo riduce significativamente il tempo di sviluppo del software, ma ne migliora anche la qualità, poiché il codice testato contiene sempre meno errori.

Chi è chi nello sviluppo POSIX

E non inizieremo con lo standard POSIX in sé, ma con l'ordinamento del ruolo delle organizzazioni coinvolte nel lavoro su di esso.

Il primo partecipante è IEEE(Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers), associazione pubblica di professionisti senza scopo di lucro. L'IEEE risale al 1884 (formalmente - dal 1963), riunisce 380.000 singoli membri provenienti da 150 paesi, pubblica una terza parte della letteratura tecnica relativa all'uso di computer, controllo, tecnologia elettrica e informatica, oltre a più di 100 riviste. popolare tra i professionisti; inoltre, l'associazione tiene oltre 300 importanti conferenze all'anno. L'IEEE ha partecipato allo sviluppo di oltre 900 standard esistenti (www.ieee.ru/ieee.htm). Oggi questo istituto è impegnato nella preparazione, coordinamento, approvazione, pubblicazione di standard, ma a causa del suo status formale non ha l'autorità per adottare tali documenti come standard internazionali o nazionali. Pertanto, il termine "standard" nella comprensione dell'IEEE dovrebbe essere inteso piuttosto come "specifica", che è più coerente con lo status dei documenti accettati dall'associazione. In conformità con l'IEEE, partecipa ai programmi di una serie di organizzazioni internazionali e regionali - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standardization) e in programmi, ad esempio, nel programma di un'organizzazione come l'ANSI.

L'IEEE include il PASC (Portable Application Standards Committee), un comitato di associazione che sviluppa la famiglia di standard POSIX (www.pasc.org/). Il PASC era precedentemente noto come Comitato tecnico dei sistemi operativi.

Il secondo partecipante al lavoro - ANSI(American National Standards Institute, American National Standards Institute) - un'organizzazione privata senza scopo di lucro che amministra e coordina negli Stati Uniti le attività di standardizzazione. Impiega solo 75 persone, ma ANSI ha oltre 1.000 membri, aziende, organizzazioni, agenzie governative e istituzioni (www.ansi.org). ANSI rappresenta gli Stati Uniti in due importanti organismi internazionali di standardizzazione, ISO e IEC.

Terzo partecipante - ISO(Organizzazione internazionale per la standardizzazione). È stato creato nel 1946 per decisione del Comitato per il coordinamento degli standard e dell'Assemblea generale delle Nazioni Unite e ha iniziato ufficialmente i lavori il 23 febbraio 1947 (www.iso.org). L'ISO è una rete di istituti di standard nazionali di 146 paesi (un paese - un membro ISO) con un segretariato centrale a Ginevra (Svizzera). Gli standard ISO sono sviluppati in comitati tecnici, il cui primo output è il Draft International Standard (DIS), che, dopo diverse approvazioni, diventa il Final Draft International Standard (FDIS). Successivamente, viene posta in votazione la questione dell'approvazione del presente documento; se ha successo, diventa uno standard internazionale.

E infine - IEC(International Electrotechnical Commission, International Electrotechnical Commission - IEC), fondata nel 1906, IEC prepara e pubblica standard internazionali per tutte le tecnologie elettriche, elettroniche e correlate (www.iec.ch/). Dal 1° novembre 2004, i comitati nazionali di 64 paesi erano membri attivi di questa commissione. L'IEC pubblica anche raccomandazioni, che sono pubblicate in inglese e francese e hanno lo status di standard internazionali. Sulla base di essi vengono sviluppati standard regionali e nazionali. I comitati tecnici (TC) sono responsabili della preparazione degli standard in vari settori dell'attività IEC, a cui partecipano i comitati nazionali interessati alle attività di un particolare TC.

L'IEC è un'organizzazione chiave nella preparazione degli standard internazionali di tecnologia dell'informazione. In questo settore esiste un comitato tecnico congiunto sulla tecnologia dell'informazione - JTC 1, costituito nel 1987 in base a un accordo tra IEC e ISO. JTC1 ha 17 sottocomitati che sovrintendono a tutto, dal software ai linguaggi di programmazione, alla grafica computerizzata e all'editing delle immagini, all'interconnessione delle apparecchiature e alle pratiche di sicurezza.

La preparazione di nuove norme IEC comprende diverse fasi (preliminare, fase di proposta, fase preparatoria, fase di comitato tecnico, fase di richiesta, fase di approvazione, pubblicazione). Se il documento IEC è destinato a diventare solo una specifica tecnica e non uno standard internazionale, una versione rivista del documento viene inviata alla sede centrale per la pubblicazione. La bozza finale dello standard internazionale (FDIS) richiederà quattro mesi per essere completata. Se approvato da tutti i membri del comitato tecnico, viene inviato all'ufficio centrale per la pubblicazione senza la fase di approvazione FDIS. Successivamente, il FDIS passa ai comitati nazionali, che devono approvarlo entro due mesi. Il FDIS si considera approvato se ha votato a favore più di due terzi dei comitati nazionali e il numero di voti negativi non supera il 25%. Se il documento non viene approvato, viene inviato per la revisione ai comitati tecnici e alle sottocommissioni. Lo standard deve essere pubblicato entro e non oltre due mesi dall'approvazione FDIS.

Diverse altre organizzazioni sono coinvolte nello sviluppo e nell'adozione degli standard POSIX.

Apri gruppoÈ un'organizzazione internazionale per la standardizzazione del software, che riunisce quasi 200 produttori e comunità di utenti che lavorano nel campo della tecnologia dell'informazione (www.opengroup.org/). L'Open Group è stato formato nel 1995 dalla fusione dei suoi due predecessori: X/Open e Open Software Foundation (OSF). The Open Group è specializzato nello sviluppo di metodologie di certificazione del software e test di conformità. In particolare, Open Group è impegnato nella certificazione per aree quali COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) e, infine, la famiglia di standard POSIX (www.opengroup.org/certification/).

Gruppo di revisione degli standard comuni di Austin (CSRG)- tecnico congiunto gruppo di lavoro costituita nel 2002 da ISO, IEC e Open Group per creare e mantenere ultime versioni standard 1003.1, che sarà formato sulla base di ISO/IEC 9945-1-1996, ISO/IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 e Single UNIX Specification (www.opengroup.org /press/ 14nov02.htm).

Istituto nazionale di standard e tecnologia (NIST)- un'agenzia federale all'interno della Technology Administration del Dipartimento del Commercio (www.nist.gov/public_affairs/general2.htm), fondata negli Stati Uniti nel 1901. La missione del NIST è sviluppare e promuovere standard e tecnologie per migliorare la qualità del prodotto. Il NIST include un laboratorio di tecnologia dell'informazione (ITL), uno dei cui risultati sono gli standard di elaborazione delle informazioni federali (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL ha offerto una serie iniziale di test per la certificazione POSIX sotto FIPS PUB 151-1 1990 nel 1991.

Cos'è POSIX?

Formalmente il termine POSIX proposto da Richard Stallman come abbreviazione di P ortable oh lavorando S interfaccia di sistema per un IX(interfaccia del sistema operativo portatile per Unix). POSIX è stato sviluppato per sistemi operativi simili a UNIX (le loro prime versioni risalgono ai primi anni '70) con l'obiettivo di fornire la portabilità dei sorgenti alle applicazioni.

La descrizione iniziale dell'interfaccia è stata pubblicata nel 1986 quando era chiamata IEEE-IX (versione IEEE di UNIX). Tuttavia, il nome è cambiato rapidamente, diventando POSIX, e già nella pubblicazione successiva (nel 1986) questa nuova versione è stato utilizzato Per qualche tempo, POSIX è stato inteso come un riferimento (o sinonimo) a un gruppo di documenti correlati IEEE 1003.1-1988 e parti di ISO / IEC 9945, e come uno standard internazionale completo e approvato ISO / IEC 9945.1: 1990 POSIX è stato utilizzato adottata nel 1990. Le specifiche POSIX definiscono un meccanismo standard per l'interazione tra un programma applicativo e il sistema operativo e attualmente include più di 30 standard sotto gli auspici di IEEE, ISO, IEC e ANSI.

Nel corso della sua storia, POSIX ha fatto molta strada, con la designazione delle specifiche, il loro contenuto specifico, le procedure e la logistica della loro verifica cambiate molte volte. Da allora, sono state emesse diverse edizioni dello standard POSIX nell'ambito di varie organizzazioni internazionali.

La storia dello sviluppo dello standard POSIX

La prima versione della specifica IEEE Std 1003.1 è stata pubblicata nel 1988. Successivamente, numerose edizioni di IEEE Std 1003.1 sono state adottate come standard internazionali.

Fasi di sviluppo POSIX:

1990 anno

L'edizione, pubblicata nel 1988, è stata rivista ed è diventata la base per ulteriori revisioni e aggiunte. È stato approvato come standard internazionale ISO/IEC 9945-1: 1990.

1993 anno

Viene pubblicata l'edizione 1003.1b-1993.

1996 anno

Sono state apportate modifiche a IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 e 1003.1i-1995, ma la maggior parte del documento rimane invariata. Nel 1996 è stata approvata anche la revisione di IEEE Std 1003.1 come standard internazionale ISO/IEC 9945-1:1996.

1998 anno

Apparve il primo standard per "tempo reale" - IEEE Std 1003.13-1998. È un'estensione dello standard POSIX per applicazioni embedded in tempo reale.

1999 anno

È stato deciso di apportare modifiche significative al testo principale dello standard per la prima volta negli ultimi 10 anni, inclusa la fusione con lo standard 1003.2 (Shell e utilità), poiché a quel tempo si trattava di standard separati. Il PASC ha deciso di finalizzare le modifiche al testo di base dopo il completamento degli standard IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q e 1003.2b.

2004 r.

La revisione più recente di 1003.1 è stata pubblicata il 30 aprile e rilasciata sotto gli auspici dell'Austin Common Standards Revision Group. Viene modificato per l'edizione 2001 dello standard. Formalmente, l'edizione 2004 è nota come IEEE Std 1003.1, 2004 Edition, The Open Group Technical Standard Base Specifications, Issue 6 e include IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 e IEEE Std 1003.1-2001 / Cor 2-2004.

I più importanti standard POSIX per RV OS

Per i sistemi operativi in ​​tempo reale, sette specifiche dello standard sono le più importanti (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), ma solo tre hanno ricevuto un ampio supporto nei sistemi operativi commerciali:

• 1003.1a (definizione del sistema operativo) definisce le principali interfacce del sistema operativo, il controllo dei lavori, i segnali, le funzioni del file system e il lavoro con dispositivi, gruppi di utenti, pipeline, buffer FIFO;
• 1003.1b (estensioni in tempo reale) descrive estensioni in tempo reale come segnali in tempo reale, invio prioritario, timer, I/O sincroni e asincroni, semafori, memoria condivisa, messaggi. Inizialmente (prima del 1993) questo standard era denominato POSIX.4.
• 1003.1c (Fili) definisce le funzioni di supporto del thread: controllo del thread, attributi del thread, mutex, invio. Originariamente designato come POSIX.4a.

Oltre a questi standard, i seguenti standard sono importanti per il sistema operativo RT, che sono stati implementati come parte del lavoro sul progetto Std 1003.1-2001:

• IEEE 1003.1d-1999. Estensioni aggiuntive in tempo reale. Originariamente designato come POSIX.4b;
• IEEE 1003.1j-2000. Estensioni in tempo reale migliorate (avanzate);
• IEEE 1003.1q-2000. Tracciamento.

Procedura di certificazione

Per essere conforme a POSIX, un sistema operativo deve essere certificato rispetto alla suite di test appropriata. Dall'introduzione di POSIX, la suite di test ha subito modifiche formali e di fatto.

Nel 1991, il NIST ha sviluppato un programma di test POSIX sotto FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Questa opzione di test era basata su IEEE 1003.3 "Standard for Test Methods for Measuring Conformance to POSIX" Draft 10, 3 maggio 1989. Nel 1993, il NIST ha completato il programma di test POSIX per FIPS 151-1 e ha iniziato il programma per FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 ha adattato "Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)", che è uno standard ISO / IEC 9945-1: 1990. Le suite di test per FIPS 151-2 erano basate su IEEE 2003.1-1992 "Standard for Test Methods for Measuring Conformance to POSIX".

Il NIST distingue tra due metodologie di certificazione: autocertificazione e certificazione da parte di laboratori di prova accreditati IEEE (Accredited POSIX Testing Laboratories - APTL). Nel primo caso, l'azienda conduce i test in proprio, ma secondo un piano approvato dal NIST. Nel secondo caso, il test viene eseguito da un laboratorio indipendente utilizzando suite di test automatizzate. In totale sono stati accreditati due laboratori APTL: Mindcraft (www.mindcraft.com) e Perennial (www.peren.com).

Nel 1997, il NIST/ITL annunciò l'intenzione di porre fine alla certificazione FIPS 151-2 alla fine di quest'anno (ufficialmente il 31 dicembre 1997), mentre l'Open Group annunciò che sarebbe subentrato dal 1 ottobre di quell'anno. anno di servizio di certificazione secondo FIPS 151-2, basato sul programma NIST/ITL. Le stesse funzioni sono state rilevate dalla IEEE Standards Association (IEEE-SA) dal 1 gennaio 1998, e anche sulla base di FIPS 151-2.

Nel 2003, IEEE-SA e Open Group hanno annunciato un nuovo programma di certificazione congiunto per le ultime versioni POSIX a partire da IEEE 1003.1 ™ 2001. L'Open Group dispone ora di diverse suite di test che coprono IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 , IEEE Std 1003.1-2003 e IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Un prodotto è considerato certificato POSIX se ha superato l'intera procedura di certificazione, in base ai risultati dei test soddisfa tutti i requisiti ed è iscritto nel registro ufficiale dei prodotti certificati.

Le suite di test includono:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - un insieme di test di conformità per interfacce di sistema IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - un insieme di test di conformità per il profilo IEEE Std 1003.13-1998 PSE54 (multiuso in tempo reale);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - un insieme di test di conformità per interfacce di sistema IEEE Std 1003.1-2003 (solo parti obbligatorie);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) è un insieme di test di conformità per IEEE Std 1003.1-2003 (shell e utilità - solo parti obbligatorie).

Inoltre, Open Group ha sviluppato benchmark per POSIX Realtime Standards e Embedded POSIX Standards Profile. La POSIX Realtime Test Suite (www.opengroup.org/testing/testsuites/realtime.html) include i seguenti test:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Estensione in tempo reale e IEEE POSIX 1003.1,2003 Edition;
• IEEE Std POSIX 1003.1c-1995 estensione Threads (pthreads) e IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 Estensione aggiuntiva in tempo reale e IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1j-2000 Advanced Realtime Extension e IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1q-2000 Trace e IEEE POSIX 1003.1,2003 Edition e IEEE POSIX 1003.1,2003 Edition;

L'Embedded POSIX Standards Profile Test Suite (www.opengroup.org/testing/testsuites/embedded.html) include i seguenti test:

• IEEE POSIX 1003.1-1990 (5310 test);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Estensione in tempo reale (1430 test);
• IEEE Std POSIX 1003.1c-1995 estensione thread (pthreads) (1232 test);
• IEEE POSIX 1003.13-1998 Profilo 52.

Un po' di confusione nella terminologia

In relazione al gruppo di standard POSIX, la lingua inglese spesso utilizza non uno, ma fino a tre termini. Sfortunatamente, hanno un significato simile e sono spesso tradotti allo stesso modo, il che introduce una certa confusione. Questi termini sono i seguenti:

• compatibilità (letteralmente - "compatibilità");
• conformità (letteralmente - "conformità");
• conformità (letteralmente - "coerenza").

Il primo termine applicato a POSIX non è definito formalmente. Il secondo significa che l'organizzazione - il produttore del prodotto software dichiara in modo indipendente che questo prodotto (in tutto o in parte) è conforme agli standard NIST-PCTS elencati. Il terzo termine implica che Software superato il sistema di test stabilito o con l'aiuto di un laboratorio accreditato o all'interno dell'Open Group e vi sono prove documentali per questo (la cosiddetta Dichiarazione di Conformità). Più avanti nel testo dell'articolo, gli originali dei termini saranno citati ovunque al fine di eliminare ambiguità.

OS certificato RV

Se aderisci a regole rigorose che richiedono che i dati su un sistema operativo RT certificato siano pubblicati nel registro ufficiale e i test vengono eseguiti a livello di conformità, al momento ci sono solo due sistemi operativi RT certificati (i dati sono forniti in ordine cronologico):

LynxOS v.3(un prodotto di Lynx Real-Time Systems, ora chiamato LynuxWorks, Inc., www.lynuxworks.com) è progettato per sviluppare software per sistemi embedded che operano in tempo reale, produttori di apparecchiature OEM e di telecomunicazione, in particolare produttori di sistemi di bordo per applicazioni militari... Lo sviluppo può essere effettuato sia sul sistema target stesso (self-hosted) che sul computer strumentale (host), il software finito è progettato per funzionare sul sistema target (target). LynxOS v.3 è conforme POSIX certificato su piattaforme Intel e PowerPC. Informazioni su questo possono essere trovate sul sito web IEEE all'indirizzo http://standards.ieee.org/regauth/posix/posix2.html. LynxOS è certificato POSIX 1003.1-1996 da Mindcraft, un laboratorio di test POSIX accreditato IEEE POSIX sulla suite di test di conformità NIST FIPS 151-2. Numero documento di certificazione: File di riferimento: IP-2LYX002, File di riferimento: IP-2LYX001.

INTEGRITÀ v.5(un prodotto di Green Hills Software, www.ghs.com) è conforme a POSIX 1003.1-2003, System Interfaces for PowerPC architecture nel luglio 2004 (http://get.posixcertified.ieee.org/select_product.tpl). Suite di test VSX-PCTS 2003.

POSIX e il sistema operativo QNX

QNX v.4.20 (sviluppato da QNX Software Systems, www.qnx.com) è certificato di conformità POSIX 1003.1-1988 per la piattaforma Intel da DataFocus Incorporated. Test condotti il ​​13 settembre 1993 e pubblicati il ​​1 novembre 1993. NIST PCTS 151-1 Test Suite, versione 1.1.

QNX Neutrino (versione 6.3) è conforme ai seguenti standard della famiglia POSIX (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).

Anche QNX Software Systems, il creatore di QNX Neutrino, sta pianificando la conformità di QNX Neutrino ad alcuni di questi standard; i lavori sono previsti per il 2005 (www.qnx.com/news/pr_959_1.html).

Letteratura

1. IEEE Standards Association Manuale Operativo. IEEE, ottobre 2004.
2. Kevin M. Obeland. POSIX in tempo reale, programmazione di sistemi integrati, 2001.
3. IEEE / ANSI Standard 1003.1: Information Technology - (POSIX) - Parte 1: Applicazione di sistema: Interfaccia di programma (API).
4. Gallemeister, B. O. Programmazione per il mondo reale, POSIX.4 Sebastopoli, CA: O'Reilly & Associates, 1995.
5. Istituto nazionale di standard e tecnologia, PCTS: 151-2, POSIX Test Suite.
6. POSIX: certificato da IEEE e The Open Group. Politica certificata. The Open Group, 21 ottobre 2003, Revisione 1.1.

Alexey Fedorchuk
anno 2005

Una delle caratteristiche distintive della struttura logica del file system dei sistemi operativi della famiglia POSIX è la loro organizzazione gerarchica, o ad albero (anche se, come ho detto, l'albero sembra un po' strano). Cioè, come in DOS o Windows di qualsiasi tipo, non esiste una designazione (ad esempio alfabetica o qualsiasi altra) per i singoli supporti e le loro partizioni: sono tutti inclusi in un'unica struttura come sottodirectory della directory principale. chiamato radice. Processo di connessione file system su un supporto fisico indipendente (e le loro partizioni) alla radice dell'albero dei file è chiamato mount e le sottodirectory che contengono sono chiamate punti di montaggio.

Storicamente, Unix ha sviluppato una struttura di directory specifica che è molto simile in tutta la famiglia in termini generali, ma leggermente diversa nei dettagli. In particolare, la gerarchia dei file sui sistemi BSD è quasi identica, ma diversa da quella su Linux. E in quest'ultimo, si riscontrano differenze significative tra le diverse distribuzioni. Fino al fatto che la struttura della gerarchia dei file è una delle caratteristiche specifiche della distribuzione.

Questo stato di cose rende difficile scrivere applicazioni multipiattaforma. E quindi esiste e sta sviluppando attivamente un progetto per standardizzare la gerarchia dei file - FHS (Filesystem Hierarchy Standard).

L'FHS aveva originariamente lo scopo di snellire la struttura delle directory di numerose distribuzioni Linux. Successivamente è stato adattato per gli altri Sistemi simili a Unix(incluso il clan BSD). E ora ci sono sforzi attivi (ma non molto riusciti) per renderlo lo standard per i sistemi POSIX, non solo di nome, ma anche di fatto.

Lo standard FHS si basa su due principi fondamentali: una netta separazione nella gerarchia dei file di directory condivise e non condivise, da un lato, e immutabili e mutevoli, dall'altro.

Il contrasto tra directory condivise e non condivise è dovuto alla natura intrinseca della rete di Unix. Cioè, i dati relativi a una macchina locale (ad esempio, i file di configurazione per i suoi dispositivi) dovrebbero trovarsi in directory separate da quelle i cui contenuti sono disponibili da altre macchine in rete, locali o globali (un esempio non è solo utente dati, ma anche programmi) ...

L'essenza dell'opposizione tra directory immutabili e mutevoli è facile da spiegare con un esempio. Quindi, gli stessi programmi utente generici per loro natura dovrebbero essere immutabili (o meglio, disponibili per la modifica solo all'amministratore di sistema, ma non all'utente stesso che li utilizza nel suo lavoro). Allo stesso tempo, questi programmi durante il loro lavoro generano non solo file di dati, ad esempio testi o immagini (la loro natura variabile è chiara senza commenti), ma tutti i tipi di informazioni di servizio, come file di registro, file temporanei e simili) . Che dovrebbero essere raggruppati in directory separate dagli effettivi file di programma eseguibile, librerie, file di configurazione, ecc. necessari per eseguirli.

Tuttavia, nonostante la promozione attiva in molte distribuzioni Linux tra le più comuni, l'FHS non ha acquisito lo status di vero standard. Esistono molte distribuzioni Linux che non utilizzano alcune delle sue disposizioni. E si correla solo parzialmente con la tradizionale gerarchia di file dei sistemi BSD.

E il motivo è che l'FHS ignora un'altra opposizione, che è molto importante per l'utente: l'opposizione di parti facilmente recuperabili del file system e quelle dei suoi componenti che sono difficili da recuperare o per niente recuperabili.

Il primo, stranamente, può essere attribuito al sistema di base stesso: dopotutto, reinstallarlo dal supporto di distribuzione, in caso di crash fatale, non è così difficile. Le parti difficili da recuperare del file system, ovviamente, includono i dati degli utenti: anche se vengono regolarmente sottoposti a backup (e quanti utenti sono così attenti?), la loro distribuzione dagli archivi richiederà molto tempo (e quasi inevitabilmente comportare delle perdite).

Inoltre, nei sistemi BSD e nelle distribuzioni Linux Source Based, classificherei tutto ciò che riguarda la gestione dei pacchetti come directory difficili da recuperare: l'albero dei port di FreeBSD o pkgsrc in NetBSD (e i sistemi che lo hanno preso in prestito), le loro controparti nelle distribuzioni Linux, il codice sorgente effettivo dei programmi portati e anche il codice sorgente del sistema. Infatti, anche se tutto questo si trova nel kit di distribuzione, questi componenti del file system, di norma, vengono tenuti aggiornati dall'utente sincronizzandosi con i server del progetto in rete (altrimenti il ​​loro utilizzo non ha senso). E la loro perdita comporterà perdite sia temporanee (soprattutto con una connessione modem) che finanziarie (poche persone sono felici possessori di un accesso gratuito a Internet).

La stretta aderenza al concetto di separazione delle directory condivise e non condivise, immutabili e immutabili, recuperabili e non recuperabili l'una dall'altra consente, all'interno di una singola gerarchia di file ad albero, di separare fisicamente i suoi singoli rami, ovvero nella forma di file system indipendenti situati su dispositivi isolati (dischi, sezioni di dischi, sezioni, partizioni, ecc.). Ci sono molte ragioni per questo - sia un aumento delle prestazioni, sia un aumento dell'affidabilità, e semplicemente per ragioni di convenienza - ma non ne parleremo ora. Perché in questo momento ciò che conta per noi è che questi rami dell'albero dei file devono essere incorporati nel file system comune.

Tipico set di directory del sistema POSIX

In effetti, per funzionare è assolutamente necessario avere un solo file system, quello montato nella directory principale dell'albero dei file (una specie di analogo dell'albero del mondo Yggdrassil). La directory principale e i suoi rami indispensabili devono costituire un singolo file system situato su un supporto: un disco, una partizione del disco, un array RAID software o hardware o un volume logico nella comprensione di LVM. E dovrebbe contenere tutti i componenti necessari per avviare il sistema e, idealmente, niente di più.

Puoi visualizzare la composizione della directory principale con il comando

$ ls -1 /

che su qualsiasi sistema POSIX mostrerà un insieme minimo di directory da gentiluomo:

Bin/boot/etc/root/sbin/

È in loro che vengono raccolti tutti i file, senza i quali il sistema non può esistere. Altre directory sono qualcosa del genere:

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

Sono a) non richiesti (almeno in teoria - è praticamente difficile farne a meno), b) non tutti sono presenti in tutti i sistemi e distribuzioni, e c) ognuno di essi può essere (e spesso lo è - se fai tutto secondo la tua mente) il punto di montaggio del proprio ramo dell'albero dei file.

Inoltre, nella maggior parte dei casi, ci sono altre due sottodirectory nella radice del file system dei sistemi operativi compatibili con POSIX:

Sviluppo / processo /

Questi sono solitamente i punti di montaggio dei file system virtuali - dispositivi e processi, rispettivamente (sebbene, se il file system dei dispositivi non viene utilizzato, la directory / dev deve essere un componente del file system radice. Infine, sui sistemi Linux, come una regola, la radice dell'albero dei file è e la directory / lib per le principali librerie di sistema, e con udev, l'inevitabile directory / sys è dove viene montato il filesystem virtuale sysfs.

File system radice

Il file system root non è condivisibile (cioè non è pensato per essere condiviso da diverse macchine sulla rete) e immutabile (cioè solo l'amministratore di sistema può apportare modifiche ad esso, ma non i programmi utente e, inoltre, non gli utenti). Inoltre, è altamente sconsigliato creare sottodirectory al suo interno in eccesso rispetto a quelle previste dallo standard (ed elencate sopra).

Il riempimento del file system root è selezionato in modo che la macchina possa avviarsi e mantenere funzionalità minime anche durante un avvio di emergenza (o in modalità utente singolo), quando tutti gli altri file system non sono montati (e, di conseguenza, i suoi rami come / usr o / var potrebbero non essere disponibili.

Di conseguenza, l'avvio della macchina è fornito dai file di directory / boot e / ecc. Il primo contiene il kernel del sistema — un file eseguibile per "scopi speciali" — e tutto ciò che è necessario per caricarlo — su Linux, ad esempio, la mappa del sistema (/etc/System.map), e su FreeBSD, kernel caricabile moduli. Tuttavia, a volte il kernel si trova direttamente nella radice del file system, quindi la directory / boot potrebbe essere completamente assente e la directory / module potrebbe essere riservata ai moduli del kernel.

La directory /etc è per i file di configurazione a livello di sistema che determinano le condizioni per il caricamento. Il suo contenuto dipende molto dal sistema (e in Linux - anche dal kit di distribuzione), e quindi non lo considererò qui - dovrò tornare su questo argomento più di una volta.

La funzionalità minima necessaria è fornita dal contenuto delle directory / bin e / sbin: contengono file eseguibili dei più importanti programmi utente e di sistema, rispettivamente, proprio quelli che ti permetteranno di eseguire un complesso di misure di riparazione e salvataggio e riportare l'auto alla forma umana dopo un guasto.

La divisione dei programmi di sistema e utente in sottodirectory root è piuttosto arbitraria. Nessuno di questi comandi è realmente pensato per risolvere i problemi degli utenti. È solo che la directory / bin contiene comandi di amministrazione, a cui di volta in volta accede (o è possibile accedere) da un utente normale, e la directory sbin è intesa per comandi che l'utente non dovrebbe conoscere. E che, nella maggior parte dei casi, non potrà comunque utilizzare per mancanza di poteri adeguati (ad esempio, i diritti di accesso richiesti ai file del dispositivo).

Per eseguire programmi POSIX (compresi quelli compilati nelle directory /bin e sbin), di norma, è necessario accedere alle funzioni delle librerie di sistema (principalmente la libreria principale di glibc). E quindi il componente (quasi) indispensabile della directory root è la sottodirectory /lib, nella quale sono assemblati.

Su Linux, la directory /lib serve un altro importante scopo — la sua sottodirectory (/lib/modules) contiene moduli del kernel caricabili (su FreeBSD, il loro posto è /boot/kernel).

In FreeBSD, la directory / lib non si trova sul filesystem di root - i componenti corrispondenti si trovano qui in / usr / lib (vedi sotto). Questo perché, storicamente, FreeBSD ha costruito i principali programmi di sistema in modo che le funzioni di libreria di cui hanno bisogno siano incorporate nei loro eseguibili (chiamati collegamenti statici, che saranno discussi nel Capitolo 14). In FreeBSD 5th branch i programmi delle directory /bin e /sbin sono collegati dinamicamente, cioè in assenza della directory /usr (e in Free è quasi sempre un ramo separato del file system) non funzionano. Per compensare ciò, esiste una directory /restore che va oltre gli standard, contenente gli stessi programmi, ma linkata staticamente (come suggerisce il nome della directory, l'unico scopo del suo contenuto sono le operazioni di salvataggio).

Infine, / radice. Questa è la normale home directory dell'utente con lo stesso nome, ovvero l'amministratore di sistema. Dal momento che non svolge alcun lavoro pratico (o almeno non dovrebbe), i suoi contenuti sono solo i file di configurazione del superutente (la shell dei comandi dell'utente, l'editor preferito e così via).

Il ramo / usr

Storicamente, la directory / usr era destinata ai programmi e ai dati utente. Queste funzioni sono ora divise tra /usr/local e /home (sebbene quest'ultima sia ora un collegamento simbolico a /usr/home per impostazione predefinita su FreeBSD). La directory /usr - non modificabile, ma condivisa - funge da repository per la maggior parte dei programmi applicativi e tutto ciò che è correlato ad essi: codice sorgente, file di configurazione, librerie condivise, documentazione e simili.

La composizione della directory / usr differisce in modo significativo tra i sistemi BSD e Linux. Nel primo contiene solo le parti integranti del sistema operativo (quello che in FreeBSD è unito dal concetto di Distribuzioni). Le applicazioni installate da porte o pacchetti hanno il loro posto nella sottodirectory / usr / local, che può rappresentare un ramo separato dell'albero dei file.

Su Linux, la directory /usr funge da repository per tutti i programmi (e i loro componenti) inclusi nel kit di distribuzione. E la sottodirectory / usr / local è solitamente intesa per programmi che sono compilati indipendentemente dal sorgente.

In ogni caso, la consueta composizione della directory /usr è la seguente (come riportato dal comando ls -1):

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

Come già accennato, la sottodirectory /usr/local è un ramo separato dell'albero dei file e pertanto verrà considerata separatamente. Lo scopo delle altre directory è il seguente:

• /usr/bin e /usr/sbin sono destinati a file eseguibili di programmi utente e di sistema (qui il confine tra loro è ancora più arbitrario che nel caso della directory radice), il cui scopo va oltre a garantire il funzionamento di base di il sistema;
• / usr / etc è per i file di configurazione delle singole applicazioni;
• / usr / include contiene i cosiddetti file di intestazione necessari per il collegamento file eseguibili con componenti di libreria;
• /usr/lib e /usr/libexec sono directory per le librerie condivise da cui dipendono le applicazioni utente;
• / usr / share - un repository dei più diversi, i cosiddetti. componenti architetturalmente indipendenti: qui puoi vedere la documentazione in diversi formati, esempi di file di configurazione e dati utilizzati dai programmi di gestione della console (caratteri, layout di tastiera) e una descrizione dei fusi orari;
• / usr / src - directory del codice sorgente; in Linux, qui viene normalmente posizionato solo il codice sorgente del kernel (kernel) del sistema, nei cloni BSD - l'intero set di codici sorgente del complesso, che in FreeBSD è chiamato Distribuzioni; Di norma, non è auspicabile collocare qui le fonti dei programmi autoassemblati;
• /usr/X11R6 - directory per i componenti del sistema X Window - file eseguibili (/usr/X11R6 /bin), librerie (/usr/X11R6 /lib), header (/usr/X11R6 /include), documentazione (/usr/ X11R6 / uomo); I file dell'applicazione X non dovrebbero essere messi qui (tranne, forse, per i gestori di finestre) - il loro posto è in / usr, / usr / local o / opt, a seconda del sistema.

Inoltre, la directory /usr può contenere le sottodirectory /usr/var e /usr/tmp — di solito collegamenti simbolici ai rami corrispondenti della directory radice. E su alcune distribuzioni Linux, la documentazione principale a livello di sistema - pagine man (nella sottodirectory / usr / man) - è collocata direttamente in / usr.

Infine, sui sistemi BSD e su alcune distribuzioni Linux Source Based (per esempio, Gentoo), la directory /usr contiene una sottodirectory per il sistema di gestione dei pacchetti: i port FreeBSD e OpenBSD (/usr/ports), le loro controparti su altri sistemi (/ usr / portage in Gentoo). Sebbene dal punto di vista dell'adesione alla lettera e allo spirito dello standard FHS (lui stesso non menziona una parola su porte e sistemi simili), un posto più logico per loro sarebbe la directory / var (vedi sotto) - e questo è esattamente ciò che viene fatto in distribuzioni come CRUX e Archlinux.

Filiale / usr / locale

Come già accennato, il ramo /usr/local in Linux è destinato a programmi autocompilati da sorgenti (non inclusi in questo kit di distribuzione). E su FreeBSD, funge da casa per la maggior parte delle applicazioni dell'utente — quasi tutto al di fuori delle distribuzioni e installato da pacchetti o port. Di conseguenza, la struttura della directory nel suo insieme segue quella del ramo / usr (con comprensibili eccezioni):

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

Anche i contenuti delle sottodirectory sono simili: gli eseguibili dei programmi (/usr/local/bin e /usr/local/sbin), le loro configurazioni (/usr/local/etc), le librerie con cui sono collegati e i loro file di intestazione ( /usr/local/lib e /usr/local/include, rispettivamente), pagine man (/usr/local/man) e tutti i tipi di materiale indipendente dall'architettura (/usr/local/share), inclusa la documentazione in altri formati.

/ Opzione ramo

La directory /opt è fornita dallo standard FHS, ma in realtà non è utilizzata in tutte le distribuzioni Linux e nei sistemi BSD è completamente assente. Tuttavia, sempre più programmi vengono scritti con l'aspettativa di un'installazione predefinita al suo interno.

Storicamente, la directory / opt è stata utilizzata in Linux per applicazioni commerciali e tutti i tipi di software non libero. Al giorno d'oggi, il suo scopo è ospitare grandi sistemi software autonomi, come la libreria Qt, KDE con tutti i suoi componenti e applicazioni, OpenOffice.org e simili. La struttura della directory dovrebbe essere /opt/pkg_name. Ecco come appare sul mio sistema (Archlinux):

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

Ciascuna delle sottodirectory ha una propria struttura interna:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2: help / LICENZA LICENZA. programma html / README README.html [e-mail protetta] Condividere / [e-mail protetta] THIRDPARTYLICENSEREADME.html utente / / opt / qt: bin / doc / include / lib / mkspecs / frasari / plugin / modelli / traduzioni /

Lo scopo delle sottodirectory all'interno di /opt/pkg_name è facilmente intuibile per analogia con /usr e /usr/local. Ad esempio, / opt / kde / bin è per gli eseguibili del sistema KDE e le sue applicazioni, / opt / kde / etc è per i suoi file di configurazione, / opt / kde / include è per i file di intestazione, / opt / kde / lib è per le librerie e / opt / kde / share - per i file condivisi, inclusa la documentazione. In KDE non c'è documentazione in formato man, se lo è, quindi (come nel caso di Gnome - non l'ho installato, questo è ciò che Gimp e applicazioni Gtk simili hanno inserito) puoi vedere / opt / pkg_name / sottodirectory man.

Puoi vedere che la struttura della directory / opt si discosta dalla tradizione POSIX storicamente stabilita (e internamente giustificata di combinare componenti dello stesso tipo in directory - file eseguibili, librerie, ecc.) E con un gran numero di programmi installati al suo interno, crea alcune difficoltà: devi o sovraccaricare la variabile $ PATH, che fornisce un rapido accesso ai comandi (che sarà discusso nel Capitolo 12), o creare una directory speciale / opt / bin e inserire collegamenti simbolici ai binari del programma eseguibile. Pertanto , in alcune distribuzioni Linux (ad esempio in CRUX) in linea di principio non viene utilizzato / opt. Come, del resto, in tutti i sistemi BSD. È possibile che sia meglio così ...

/ Ramo Var

Come suggerisce il nome, la directory /var ha lo scopo di memorizzare i file modificabili generati durante la normale vita di vari programmi: cache del software (ad esempio browser), file di registro, spooling di stampa e sistemi di posta. cassette postali, descrizioni dei processi in esecuzione e così via. In particolare, è nella directory /var che vengono posizionati i cosiddetti dump, istantanee dello stato della RAM, generate durante uno spegnimento di emergenza per identificarne le ragioni. Una caratteristica distintiva di tutti questi componenti è la loro natura mutevole durante una sessione di lavoro e il fatto che, tuttavia, devono essere preservati al riavvio del sistema.

La struttura interna di /var varia molto da sistema a sistema, e quindi non mi dilungo sui dettagli della sua struttura. Noterò solo che questa directory è un luogo logico per posizionare componenti di tutti i tipi di sistemi di gestione dei pacchetti simili a porte, come avviene, ad esempio, nella distribuzione Archlinux, dove la sottodirectory / var / abs (abs - Archlinux Building System ) gli è riservato.

Directory / mnt

La directory /mnt è progettata per montare i file system utilizzati temporaneamente, solitamente situati su supporti rimovibili... In un sistema consolidato, di solito è vuoto e la sua struttura non è regolata in alcun modo. L'utente è libero di creare al suo interno sottodirectory per determinati tipi di media. Ad esempio, sul mio sistema, questi sono / mnt / cd, / mnt / dvd, / mnt / usb e / mnt / hd - per CD, DVD, unità flash e dischi rigidi rimovibili.

In FreeBSD, le directory predefinite per montare CD e floppy sono / cdrom e / floppy direttamente nella directory principale. Il che non è del tutto d'accordo con lo standard, ma a suo modo è logico: i punti di montaggio dei dispositivi esistenti (come un CD ROM) o fino a poco tempo fa (un'unità floppy) in qualsiasi macchina vengono portati alla radice.

/ Filiale domestica

La directory /home è per ospitare le directory home degli utenti. Il suo contenuto non è regolamentato in alcun modo, ma di solito assomiglia a /home/(username1,...,username#). Tuttavia, in sistemi di grandi dimensioni con un numero elevato di utenti, le loro home directory possono essere raggruppate.

La directory /home può contenere le directory home non solo degli utenti reali, ma anche di alcuni utenti virtuali. Quindi, se la macchina viene utilizzata come server web o ftp, vedrai sottodirectory come /home/www o /home/ftp, rispettivamente.

Il ramo /tmp

Resta da parlare solo della directory per l'archiviazione dei file temporanei - / tmp. Come i componenti / var, sono generati da vari programmi durante la loro vita normale. Ma, a differenza di / var, i componenti / tmp non dovrebbero essere salvati al di fuori della sessione corrente. Inoltre, tutte le guide per l'amministrazione del sistema consigliano regolarmente (ad esempio, al riavvio della macchina) o la cancellazione periodica di questa directory. E quindi, come / tmp, è consigliabile montare i file system nella RAM - tmpfs (in Linux) o mfs (in FreeBSD). Oltre al fatto che ciò garantisce che il suo contenuto venga cancellato al riavvio, contribuisce anche alle prestazioni, ad esempio, la compilazione di programmi i cui prodotti temporanei non vengono scritti su disco, ma vengono inseriti in una directory virtuale come / tmp / obj.

Su molti sistemi, vedrai directory come / usr / tmp e / var / tmp. Questi sono solitamente collegamenti simbolici a / tmp.

Strategia di partizionamento del file system

In conclusione della conversazione sulla gerarchia dei file, va sottolineato che solo le directory elencate nel paragrafo File system radice... Tutte le altre directory - /usr, /opt, /var, /tmp e, ovviamente, /home possono rappresentare i punti di montaggio di file system indipendenti su supporti fisici separati o sulle loro partizioni.

Inoltre, in rete locale queste directory potrebbero trovarsi anche su macchine diverse. Ad esempio, un computer che funge da server delle applicazioni potrebbe contenere le directory /usr e /opt sulla rete, un altro un file server che potrebbe contenere tutte le directory home dell'utente e così via.

L'unica cosa che resta da fare è decidere quali file system dovrebbero essere isolati dall'albero dei file comuni e perché dovrebbe essere fatto. La risposta a queste domande dipende molto dal sistema operativo utilizzato e, nel caso di Linux, anche dalla sua distribuzione. Tuttavia, è possibile delineare i principi generali di separazione dei file system. Perché dovremmo ricordare l'opposizione, da un lato, di directory immutabili e mutevoli, dall'altro, di dati facilmente recuperabili, difficili da recuperare e praticamente irrecuperabili. Facciamo questo tentativo in relazione a un desktop utente: nel caso di un server, i calcoli saranno significativamente diversi.

Ovviamente, il file system di root nelle directory /bin, /boot, /etc, /root, /sbin, contenente dati facilmente recuperabili dal supporto di distribuzione e dati praticamente invariati, dovrebbe trovarsi su una partizione del disco isolata. Su Linux, dovrebbe essere aggiunta anche la directory /lib. D'altra parte, quando si utilizza GRUB come boot loader (indipendentemente dal sistema operativo), si consiglia di spostare la directory /boot in una partizione separata.

Nelle vecchie fonti su Linux, puoi leggere un altro motivo per allocare una partizione per la directory / boot e all'inizio del disco: a causa dell'impossibilità di caricare il kernel con Lilo da un numero di cilindro superiore a 1023. In versioni moderne di boot loader, non ci sono tali restrizioni. Tuttavia, se stai creando una partizione per / boot, ha senso renderla la prima sul disco e posizionare la partizione di swap direttamente dietro di essa: questo aggiungerà cinque copechi alla velocità durante l'esecuzione dello scambio.

E anche dal regno della storia: anche il requisito che le partizioni di root e di avvio siano primarie è stato rimosso molto tempo fa. E questi file system possono adattarsi bene alle partizioni logiche all'interno di una partizione estesa.

È altrettanto chiaro che i rami mutabili del file system — / var e / tmp — devono essere spostati all'esterno della partizione di root. Inoltre quest'ultimo, come è stato detto più volte in precedenza, è generalmente consigliabile posizionarlo sul file system in RAM (tmpfs o mfs). Nel caso in cui la directory /var contenga sottodirectory per sistemi di gestione dei pacchetti simili a porte, come /var/abs, /var/cache/pacman/src e /var/cache/pacman/pkg in Archlinux, dovrebbero anche formare il proprio file sistemi.

Ora la directory / usr, che contiene i componenti del sistema di base (come in BSD) o la maggior parte delle applicazioni utente (come nella maggior parte delle distribuzioni Linux). Contiene dati facilmente recuperabili e, per una buona ragione, dovrebbe essere praticamente immutabile, e quindi, ovviamente, merita di essere evidenziato in una sezione indipendente. Inoltre, è consigliabile isolare dalla sua composizione, da un lato, le sottodirectory /usr/X11R6 e /usr/local, dall'altro, le sottodirectory per i sistemi di gestione dei pacchetti di tipo port: /usr/ports, /usr / pkgsrc e / usr / pkg nei sistemi BSD. , / usr / portages su Gentoo Linux e così via. Inoltre, le sottodirectory per posizionare i sorgenti scaricati dalla rete durante la creazione delle porte dovrebbero essere separate da queste ultime: /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles e simili.

Nei sistemi BSD, inoltre, ha senso separare dalla directory /usr le sottodirectory /usr/src e /usr/obj, che contengono i sorgenti dei componenti di base (incluso il kernel) e i loro prodotti intermedi di compilazione, che sono generato dalle procedure make buildworld e make buildkernel. ...

Infine, la directory /home, che contiene dati volatili e spesso irrecuperabili, deve essere rimossa dalla radice della gerarchia dei file senza fallo. E cerco sempre di posizionarlo su una fetta separata (in BSD) o sulla partizione primaria (in Linux).

Lo schema di partizionamento del file system proposto può sembrare eccessivamente complicato. Tuttavia, garantisce l'isolamento di dati facilmente recuperabili, difficili da recuperare e non recuperabili, il che rende più facile reinstallare il sistema in caso di emergenza e persino migrare da un sistema all'altro.

Il suo ulteriore vantaggio è che per i singoli rami dell'albero dei file, a seconda della natura dei dati che si trovano su di esso, in Linux, è possibile scegliere un file system fisicamente ottimale. Ad esempio, non ha senso utilizzare qualcosa di diverso da Ext2fs per la partizione in /boot. In genere si consiglia di formattare la partizione di root con un Ext3fs sicuro e tuttavia più compatibile. Per le directory con un numero enorme di piccoli file, come / var / abs in Archlinux, / usr / portages in Gentoo, è consigliabile utilizzare ReiserFS: dopo tutto, la gestione abile di piccoli file è il suo profilo. E nella directory / home, dove possono apparire enormi file multimediali (e che di solito è di per sé molto grande), XFS può arrivare in tribunale (anche se, come mostrano le misurazioni, ReiserFS sembra abbastanza decente qui). Tali misure possono migliorare sia l'affidabilità dell'archiviazione dei dati che la velocità delle operazioni sui file.

Gli utenti dei sistemi operativi BSD sono legati ai filesystem FFS senza alcuna alternativa. Tuttavia, hanno anche margini di manovra. Innanzitutto, variando la dimensione del blocco e il frammento dei singoli file system, che contribuisce o alle prestazioni delle operazioni del disco o al risparmio di spazio su disco. E in secondo luogo, alcuni rami dell'albero dei file (come / tmp o / usr / obj, contrariamente alle raccomandazioni, possono essere montati senza paura in modalità puramente asincrona, guadagnando su questo una percentuale o altre prestazioni.

A proposito di standard in generale

C'è un'opinione tra i programmatori praticanti che gli standard nella programmazione non sono affatto necessari, perché:

(1) sono inizialmente prive di significato, poiché i loro autori non scrivono programmi per computer;

(2) incatenano l'iniziativa dei programmatori;

(3) i programmatori saranno sempre d'accordo senza standard.

Forse questa opinione non avrebbe dovuto essere presa in considerazione, se non per due circostanze:

(1) è espresso dai professionisti, cioè proprio da coloro che "emettono software";

(2) Il ragionamento di cui sopra è stato scoperto dall'autore di questo articolo in una delle pubblicazioni su Internet dedicate allo standard per il linguaggio di programmazione C, da cui è emerso che tale opinione è diffusa "su scala internazionale", e non solo tra gli arroganti "super programmatori" russi.

La parola "standard" è solitamente associata a qualcosa di materiale (dimensioni standard, tensione elettrica standard, ecc.), mentre un programma per computer è un oggetto intangibile ("Il nuovo intangibile"), e forse gli standard nella sfera immateriale sono davvero privi di significato?

C'è, tuttavia, un esempio confutabile. L'insieme delle regole di ortografia della lingua russa è essenzialmente uno standard, sebbene non approvato dagli organismi di standardizzazione. Inoltre, oltre alle regole (o, se preferite, ai requisiti) dell'ortografia, ci sono regole sintattiche e, soprattutto, semantica. Quest'ultimo illustra bene la domanda "infantile": perché un gatto si chiama gatto? C'è una risposta esatta a questa domanda: perché i nostri antenati erano d'accordo; gli antenati degli inglesi accettarono di chiamare lo stesso gatto bestia, gli antenati dei tedeschi - gattino, ecc. E in generale, il significato, o la semantica, o le regole di interpretazione di qualsiasi parola o combinazione di parole è una questione di accordo.

Scopo e "super compito" dello standard POSIX

Come suggerisce il nome, POSIX (Portable Operating System Interface) è uno standard per l'interfaccia (interfaccia) tra un sistema operativo e un programma applicativo. I giorni in cui i programmatori scrivevano programmi per una macchina "nuda" (implementando i propri pacchetti di programmi di input/output, funzioni trigonometriche, ecc.) sono finiti per sempre. Il testo POSIX sottolinea ripetutamente che lo standard non impone alcun requisito sui dettagli di implementazione del sistema operativo; può essere visto come un insieme di accordi tra programmatori di applicazioni e sviluppatori di sistemi operativi. Pertanto (di nuovo, contrariamente all'opinione piuttosto diffusa), POSIX è di interesse non solo per gli sviluppatori di sistemi operativi, ma principalmente per una categoria molto più ampia di programmatori - applicati.

La necessità di uno standard di questo tipo è stata riconosciuta già negli anni '80, quando i sistemi operativi UNIX si sono diffusi. Si è scoperto che sebbene questo sistema fosse concepito come un sistema unificato, le differenze tra le sue implementazioni specifiche portavano al fatto che i programmi applicativi scritti per un sistema non potevano sempre essere eseguiti in un altro. È questo problema, noto come problema della portabilità del software, che POSIX mira a risolvere. La prima edizione dello standard è stata rilasciata nel 1988 (c'è una traduzione, vedi), in cui tutta la varietà di questioni relative alla portabilità del programma è stata divisa in due parti: (1) interfaccia del programma applicativo, (2) interprete dei comandi e utilità (interfaccia utente); queste parti sono chiamate POSIX.1 e POSIX.2, rispettivamente1.

Precisiamo che in questo articolo parleremo solo dello standard per l'interfaccia del programma applicativo, POSIX.1, la cui seconda (ed ultima ad oggi) edizione è stata approvata il 12 luglio 1996.

La parte informativa dello standard sottolinea inoltre che POSIX non è una descrizione dell'interfaccia di qualche sistema operativo "ideale", ma il risultato della generalizzazione e sistematizzazione dell'esperienza maturata nello sviluppo di sistemi operativi UNIX. Inoltre, POSIX non può fungere da guida o Guida allo studio sui sistemi operativi, sebbene la parte informativa contenga raccomandazioni per programmatori e frammenti di programma.

Lo standard afferma direttamente che è impossibile creare un sistema operativo completo, concentrandosi esclusivamente sulle funzioni di interfaccia descritte in esso. (In particolare, POSIX.1 non affronta questioni come la rete e le funzioni di interfaccia associate o l'interfaccia grafica.) Tuttavia, i costi finanziari associati all'immobilità dei programmi e alla conseguente necessità di unificazione dell'interfaccia sono così grandi che la maggior parte dei fornitori preferisce avere almeno uno standard che non ne abbia. Per questo motivo, molti sviluppatori di software tendono a concentrarsi su POSIX. Ciò consente, se non di eliminare completamente l'immobilità dei programmi, almeno di ridurre significativamente la parte immobile del programma.

A proposito di semantica

Come discusso in precedenza, POSIX può essere visto come un insieme di accordi tra uno sviluppatore di sistemi operativi e un programmatore di applicazioni. "Accordo" significa, prima di tutto, la stessa interpretazione (semantica) di parole ed espressioni. I seguenti sono esempi per illustrare la difficoltà di raggiungere un "accordo".

Come trasmettere un significato nella traduzione

Innanzitutto, va ricordato che lo standard POSIX è scritto in inglese, che per sua natura provoca ambiguità (ad esempio, la stessa parola può essere un sostantivo, un aggettivo e un verbo), e le "trappole semantiche" sono in agguato su quasi ogni pagina. Una buona illustrazione di ciò che è stato detto è un esempio tratto dalla finzione. Una delle opere più famose di Oscar Wilde, che ha usato brillantemente questa caratteristica di lingua inglese, - L'importanza di chiamarsi Ernesto - noto in russo come "L'importanza di chiamarsi Ernesto". ma nome inglese ha un secondo significato: Earnest (serio) è il nome di uno dei personaggi, e il nome potrebbe essere tradotto diversamente: "Quanto è importante essere Ernst". C'è un cognome russo Serebryany, e se ci fosse un cognome Serious, la traduzione sarebbe perfettamente accurata, con il trasferimento di entrambi i significati.

La situazione è simile con il nome stesso dello standard: Portable Operating System Interface. L'aggettivo Portable (mobile) si riferisce sia al sistema operativo che al programma applicativo, ma non può essere espresso altrettanto brevemente in russo, può essere tradotto come "Interfaccia di un sistema operativo mobile" o "Interfaccia di un sistema operativo che fornisce mobilità dei programmi applicativi”. La seconda opzione riflette meglio le intenzioni degli sviluppatori dello standard, ma allo stesso tempo si perde il primo significato (durante la traduzione, è stata mantenuta la prima opzione più familiare).

Semantica della parola "standard"

Il testo principale della norma è preceduto da un preambolo, che spiega il significato delle parole IEEE Standards2. Come segue da queste spiegazioni, ci sono almeno tre differenze semantiche dal termine in lingua russa GOST:

(1) Intuitivamente, si ritiene che GOST abbia forza di legge, la cui violazione è perseguita; POSIX è un insieme di requisiti, il cui rispetto è del tutto volontario.

(2) GOST è valido fino alla cancellazione (molti probabilmente hanno sentito l'espressione "GOST non è stato cancellato"); il preambolo di POSIX dice che se uno standard non è stato rivisto per 5 anni, ciò significa che le questioni discusse in esso potrebbero aver perso la loro rilevanza e può essere considerato annullato automaticamente;

(3) GOST è anonimo; la parte introduttiva di POSIX fornisce un elenco di coloro che hanno partecipato allo sviluppo di questo standard e fornisce anche un indirizzo a cui inviare le richieste di interpretazione; stabilisce inoltre che la risposta a ciascuna richiesta è soggetta a procedura di approvazione (in altre parole, gli autori della norma si accordano tra loro prima di dare una risposta).

Pertanto, la traduzione anche di una parola così nota come Standard con la parola "standard" richiede commenti.

La semantica delle parole "dovrebbe", "non specificato", "non definito", "definito dall'implementazione"

La sezione 2 dello standard è denominata Terminologia e requisiti generali. Contiene definizioni non solo di termini speciali (come "processo" o "semaforo"), ma anche parole apparentemente evidenti come "dovrebbe" o "può". Poiché POSIX.1 è uno standard di interfaccia, i suoi requisiti si applicano sia al sistema operativo che al programma applicativo. Un requisito esplicito è espresso dalla parola "shall", ad esempio: "Se ha successo, la funzione link() deve restituire zero". In questo esempio, stiamo parlando di un requisito del sistema operativo: la funzione link() deve essere implementata in modo che restituisca zero in caso di successo.

I termini "non specificato" e "non definito" esprimono la stessa idea che lo standard consente la libertà di scelta, ma il significato di questi termini è diverso. Il termine "non specificato" significa che stiamo parlando di alcune corrette (azioni, costruzioni di programmi, ecc.) E il termine "non definito" - su errato (erroneo). La parte informativa della norma fornisce la seguente spiegazione.

Il termine "non specificato" significa che si presume che una varietà di opzioni (risultati, risultati di una chiamata di funzione, ecc.) siano note e lo standard ne consente una qualsiasi; in una particolare implementazione di un sistema operativo, qualsiasi può essere scelto e tale sistema è considerato conforme allo standard. Il programma applicativo (rigorosamente conforme allo standard) deve essere scritto in modo tale da funzionare correttamente in ogni sua variante; in quanto tale, il termine esprime implicitamente un requisito per un programma applicativo.

Facciamo un esempio: “La funzione readdir() dovrebbe restituire un puntatore a una struttura che fa riferimento all'elemento successivo della directory. La norma non specifica se gli elementi del catalogo denominati "punto" e "punto-punto" vengano restituiti o meno. " In questo esempio, ci sono quattro possibili risultati e il requisito per l'applicazione è che deve essere progettato per uno di essi.

Un altro esempio: “Se la funzione sigwait(), che indica di attendere un segnale con il numero specificato, viene chiamata in più thread di controllo, quando un segnale arriva in non più di uno di essi, sigwait() deve tornare. In che tipo di flusso di controllo ciò accadrà non è specificato dallo standard. " In questo esempio, potrebbero esserci molti più risultati possibili, ma tutti sono anche noti e il requisito per l'applicazione è che debba funzionare correttamente per qualsiasi risultato.

Il termine "non definito" implica che anche molti esiti non sono noti, qualsiasi risultato è possibile, anche disastroso (ad esempio, crash del sistema, perdita di dati, ecc.). In sostanza, questo termine esprime implicitamente un requisito per un programma applicativo di non utilizzare i dati oi costrutti corrispondenti. Ad esempio: "Se l'argomento dirp di readdir() non fa riferimento alla directory attualmente aperta, il risultato non è definito".

Questo esempio richiede che l'applicazione sostituisca solo un riferimento alla directory aperta per l'argomento della funzione readdir(); la violazione di questo requisito può portare a conseguenze disastrose e la responsabilità di ciò spetta al programmatore dell'applicazione.

Ecco un altro esempio: “Se ha successo, la funzione read() dovrebbe restituire un numero intero che rappresenta il numero di byte effettivamente letti. In caso contrario, la funzione deve assegnare il codice di errore a errno e restituire -1 e il contenuto del buffer a cui punta buf non è definito. "

Lo standard proibisce l'uso dei dati dal buffer nel programma applicativo in caso di errore nella funzione read() e le conseguenze della violazione di questo requisito sono assegnate al programmatore dell'applicazione.

Il significato del termine "definito dall'implementazione" è diverso da quello intuitivo. Ovviamente, in uno specifico sistema operativo non può esistere un risultato "non specificato" o "non definito", qualche risultato specifico si otterrà senza fallo. Il termine "definito dall'implementazione" esprime il requisito dello standard per la documentazione del sistema operativo: il risultato non deve essere solo specificato (lo sviluppatore del sistema operativo dovrà comunque farlo), ma anche riflesso esplicitamente nella documentazione del sistema.

Semantica predefinita

Non un singolo documento normativo può coprire l'intera varietà di casi che possono verificarsi nella pratica, quindi è inevitabilmente silenzioso su qualcosa3. Ad esempio, la descrizione di una funzione può dire che il suo argomento può assumere valori da un certo intervallo, ma non viene detto nulla su quale sarà il risultato se l'argomento non rientra in questo intervallo. Ovviamente, per evitare fraintendimenti, è necessario avere una semantica di default uniforme. Nella parte informativa dello standard c'è una frase interessante: "la semantica generalmente accettata di default è proibita". Questa affermazione contraddice il noto slogan di dieci anni fa "tutto è permesso ciò che non è esplicitamente proibito". Apparentemente, è così radicato nella mente dei cittadini che molti, anche i programmatori, non sono d'accordo con la citata dichiarazione dello standard. Nel frattempo, se l'uso di qualsiasi costrutto non è esplicitamente consentito e non segue dalla descrizione, allora qualsiasi programmatore praticante si rende conto che utilizzarlo è rischioso e, se non funziona, non gli viene in mente di fare un'affermazione.

Processi e flussi di controllo

Entrambi questi termini esprimono l'idea di esecuzione parallela. Il sistema operativo UNIX è stato originariamente concepito come multiutente e i programmi lanciati da utenti diversi devono essere isolati in modo sicuro l'uno dall'altro in modo da non distorcere accidentalmente dati "estranei". Questo isolamento è fornito dal fatto che il programma utente viene eseguito all'interno di un processo che si sviluppa nel proprio spazio di indirizzi virtuale. Anche se il programma contiene dati globali, quando viene avviato in processi diversi, verranno automaticamente "divorziati" in spazi di indirizzi diversi.

Tuttavia, il meccanismo di processo non è del tutto soddisfacente quando si programmano attività in tempo reale. Un'applicazione in tempo reale (in esecuzione per conto dello stesso utente) può spesso essere rappresentata naturalmente come parti in esecuzione simultanea chiamate "thread". La loro differenza più significativa rispetto ai processi è che tutti i flussi di controllo si sviluppano in un unico spazio di indirizzamento; ciò fornisce un rapido accesso ai dati globali, ma allo stesso tempo c'è il rischio di una loro distorsione involontaria e, per evitare che ciò accada, è necessario osservare una certa disciplina di programmazione. Le relative raccomandazioni sono contenute nella parte informativa della norma.

Va sottolineato che l'idea del multithreading è implementata in molti sistemi operativi real-time, e implementata in modi diversi, nel senso che ogni thread di controllo ha un diverso insieme di attributi e funzioni di interfaccia; a volte si usa il termine task al posto di thread. Per evitare confusione, lo standard sottolinea che si occupa esclusivamente di thread POSIX e i nomi delle funzioni di interfaccia corrispondenti sono preceduti da pthread_ (ad esempio, pthread_create (), pthread_join (), ecc.).

Conformità alla norma. Semantica della parola "match"

Intuitivamente, si ritiene che se due articoli sono realizzati secondo lo stesso standard, è garantito che si "accoppiano" l'uno con l'altro e lavoreranno insieme in coppia; questo è precisamente lo scopo di introdurre uno standard di interfaccia (interfaccia). Poiché POSIX è uno standard per un'interfaccia, possiamo parlare di conformità allo standard sia del sistema operativo che del programma applicativo.

Lo standard POSIX.1 contiene diverse centinaia (se non migliaia) di requisiti; si considera evidente che se almeno uno di essi non è soddisfatto, allora il sistema (o programma applicativo) non è conforme allo standard. Allo stesso tempo, fino ad oggi sono stati scritti così tanti sistemi operativi e programmi applicativi di classe UNIX che è difficilmente ragionevole richiedere la piena conformità nel senso indicato. Le difficoltà nello sviluppo di uno standard internazionale di questo tipo sono aggravate dall'esistenza di diverse lingue nazionali. Anche se ci dimentichiamo dei programmi applicativi destinati all'elaborazione dei testi nelle lingue nazionali, quasi tutti i programmi applicativi devono emettere qualche tipo di messaggio diagnostico e/o percepire i testi inseriti dall'operatore.

• rigoroso rispetto dello standard POSIX.1;
• conformità alla versione internazionale POSIX.1;
• conformità alla versione nazionale di POSIX.1;
• POSIX.1 conformità con le estensioni.

In secondo luogo, molte delle funzionalità di interfaccia sono opzionali; Lo standard richiede che le funzioni di interfaccia opzionali siano gestite come prescritto dallo standard o restituiscano sempre un codice di errore speciale, ENOSYS (il che significa che la funzione non è implementata). I servizi facoltativi sono suddivisi in più gruppi, ognuno dei quali corrisponde ad una costante di configurazione, che viene dichiarata (dall'operatore #define) nel corrispondente file di intestazione; questo permette di scoprire se una funzione è stata implementata durante la fase di compilazione.

Il metodo descritto per ottenere la mobilità non è stato inventato dagli autori di POSIX, ma è stato a lungo utilizzato nella pratica; su molti sistemi operativi, le costanti di configurazione vengono utilizzate per identificare il sistema stesso o la sua versione. E qui lo standard non offre nulla di fondamentalmente nuovo, ma sistematizza solo la pratica esistente.

Oggetti della standardizzazione e struttura della norma

In breve, gli oggetti di standardizzazione POSIX.1 sono nomi e semantica. Più specificamente, stiamo parlando di quanto segue.

• I nomi delle funzioni dell'interfaccia. 357 funzioni sono standardizzate, con 107 funzioni prese da librerie C standard (matematiche, elaborazione stringhe, input/output, ecc.); queste funzioni sono considerate parte dello standard POSIX.1, ma lo sono Descrizione completa contenuto nello standard per il linguaggio di programmazione C.
• Nomi dei tipi di dati di sistema. Questi nomi sono suffissi con _t.
• I nomi dei file di intestazione, nonché la composizione minima di questi file.
• Nomi di variabili globali a livello di sistema (ad esempio, errno).
• Nomi simbolici dei codici di errore che possono essere impostati durante l'esecuzione della funzione. Questi nomi iniziano con la lettera E (EPERM, ENOTEMPTY, ecc.).
• Nomi delle costanti di configurazione. Questi nomi sono preceduti da _POSIX_.
• Nomi simbolici di numeri di segnale; questi nomi sono preceduti da SIG. Oltre a 20 segnali "tradizionali" (SIGABRT, SIGALRM, ecc.), vengono standardizzati segnali in tempo reale, i cui numeri devono occupare un certo intervallo continuo da SIGRTMIN a SIGRTMAX compreso, contenente almeno i numeri RTSIG_MAX.
• Nomi simbolici corrispondenti ai valori dei singoli argomenti di alcune funzioni (ad esempio, l'argomento cmd della funzione fcntl() può assumere i valori F_DUPFD, F_GETFD, F_GETLK, ecc.).
• Nomi di macro, costanti, bit flag, variabili d'ambiente.

In generale, lo standard è costituito da due grandi parti di circa lo stesso volume. La prima metà - la parte normativa - contiene i requisiti e le raccomandazioni dello standard (18 sezioni), la seconda - la parte informativa - contiene Appendici, che forniscono un elenco di riferimenti, commenti e spiegazioni alla parte normativa, la composizione dell'intestazione file, un esempio di profilo ("proiezione") dello standard ( per la Danimarca), caratteristiche e metodologia per misurare le prestazioni delle funzioni più importanti, nonché una descrizione di funzioni di interfaccia aggiuntive per lavorare con i file in tempo reale; si prevede che nelle future edizioni della norma queste funzioni saranno incluse nella parte normativa.

La barra laterale "Riepilogo delle clausole dello standard" dà un'idea di quali tipi di servizi del sistema operativo sono coperti dallo standard.

Conclusione

Il contenuto principale dello standard POSIX è la semantica delle funzioni di interfaccia. La standardizzazione della semantica non è di per sé un'impresa facile (tutti sanno quanto sia difficile mettersi d'accordo anche per due persone), e le difficoltà sono aggravate dal fatto che attualmente molte persone sono coinvolte nella programmazione. Ad esempio, il paradigma della concorrenza è espresso in termini come "processo", "attività" e "flusso di controllo", ma da un punto di vista pratico della programmazione, "attività" nel sistema operativo IBM OS / 360 e il reale- il sistema operativo del tempo VxWorks non è lo stesso e anche. Un altro esempio sono i semafori. I semafori sono binari, interi ("con un contatore") e mutua esclusione (che, tra l'altro, i programmatori chiamano tra loro "mutex", cercando spontaneamente di evitare fraintendimenti). E i semafori interi, ad esempio, nel sistema operativo VxWorks, non sono affatto uguali ai semafori POSIX.

Gli autori dello standard POSIX, ben consapevoli di quanto sia difficile indurre le persone ad abbandonare le proprie abitudini (che chiamano "pratica consolidata"), dichiarano di aver compilato un sistema coerente e minimale di funzioni di interfaccia che copre la maggior parte dei servizi tradizionalmente fornite dal sistema operativo, hanno descritto dettagliatamente l'esatta semantica di queste funzioni e invitano tutti ad utilizzarle nei loro sviluppi4.

Leggendo lo standard, a volte si ha l'impressione che alcune diciture avessero un unico scopo: non rimuovere alcuni programmi applicativi o sistemi operativi dalla categoria di soddisfacimento dello standard. Tale obiettivo è stato infatti fissato ed esplicitamente formulato nell'Introduzione: lo standard dovrebbe tenere conto il più possibile della pratica prevalente. Tuttavia, l'obiettivo principale resta quello di garantire la mobilità dei programmi applicativi.

Circa l'autore

Sergey Romanyuk - ricercatore senior presso l'Istituto di ricerca per la ricerca sui sistemi, capo del gruppo di traduttori standard POSIX. Può essere contattato via e-mail all'indirizzo: [e-mail protetta]

1 Va aggiunto che il lavoro sullo standard va avanti da molti anni; vengono individuate nuove emissioni, che vengono o inserite in una delle parti esistenti, o formalizzate in una parte separata, che può essere successivamente cancellata. Ciò è accaduto, ad esempio, con le strutture front-end in tempo reale, inizialmente dichiarate come POSIX.4 e successivamente incluse in POSIX.1.

2 L'IEEE è l'organizzazione che ha sviluppato lo standard POSIX.

3 Qui "predefinito" significa silenzioso, non predefinito; non stiamo parlando di alcun valore implicito che viene effettivamente dichiarato, ma dell'assenza di riferimenti.

4 Una traduzione russa dello standard sarà pubblicata all'inizio del 2000.

Letteratura

Standard internazionale ISO/IEC 9945-1 (ANSI/IEEE Std 1003.1) Seconda edizione. 1996-07-12. Tecnologia dell'informazione - Interfaccia del sistema operativo portatile (POSIX) - Parte 1: Interfaccia del programma applicativo del sistema (API).

M.I. Belyakov, Yu.I. Rabover, A.L. Fridman. Sistema operativo mobile. Elenco. Mosca, "Radio e comunicazione", 1991.

ISO/IEC 9899:1990, Linguaggi di programmazione - C.

Sezione 1	- Introduzione
Sezione 2	- Terminologia e definizioni
Sezione 3	- Funzioni per la gestione dei processi (creazione, sostituzione di un'immagine, completamento) e dei segnali (gestione delle maschere, risposta ai segnali)
Sezione 4	- Identificazione (processi, utenti, sistema, terminale), polling del tempo impiegato per l'esecuzione del processo, polling delle variabili d'ambiente.
Sezione 5	- Gestione di file e directory
Sezione 6	- Funzioni di ingresso e uscita
Sezione 7	- Funzioni di controllo del terminale
Sezione 8	- Funzioni mutuate dallo standard del linguaggio C
Sezione 9	- Accesso a database di utenti e gruppi di utenti
Sezione 10	- Formati dati per archiviazione e scambio (tar e cpio)
Sezione 11	- Strutture di sincronizzazione: semafori, mutex e variabili di condizione
Sezione 12	- Funzioni di gestione della memoria: pinning e unpinning dello spazio degli indirizzi del processo, mappatura dei file in memoria, protezione della memoria, memoria condivisa
Sezione 13	- Funzioni relative alla programmazione dei processi e dei flussi di controllo
Sezione 14	- Gestione orologio e timer
Sezione 15	- Gestione della coda dei messaggi
Sezione 16	- Funzioni di base relative ai flussi di controllo
Sezione 17	- Dati specifici del thread
Sezione 18	- Mezzi di distruzione dei flussi di controllo

Oggetto: Sistemi operativi.
Domanda: No. 8

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

Principi di costruzione del sistema operativo:

1.) Principio di modularità- per modulo si intende generalmente un elemento funzionalmente completo del sistema, realizzato secondo le interfacce intermodulari accettate. Per sua definizione, un modulo presuppone la possibilità di sostituirlo facilmente con un altro, a condizione che siano disponibili le interfacce specificate. In larga misura, la divisione del sistema in moduli è determinata dal metodo di progettazione del sistema operativo utilizzato (bottom-up o viceversa).

I moduli privilegiati, rientranti e rientranti sono di particolare importanza quando si costruisce un sistema operativo (re-entitlement è letteralmente re-entitlement; un termine speciale per indicare lo stato di salute di un programma; la proprietà di un programma da eseguire correttamente con una chiamata ricorsiva (restituita) da un interrupt).

L'effetto maggiore dall'uso di questo principio è ottenibile nel caso della contemporanea estensione di questo principio al sistema operativo, ai programmi applicativi e all'hardware.

2.) Principio di selettività funzionale- una certa parte dei moduli importanti è allocata nel sistema operativo, che deve essere costantemente posizionato nella RAM per un'organizzazione più efficiente del processo di elaborazione. Questa parte è chiamata kernel nel sistema operativo, poiché è la base del sistema. Nella formazione della composizione del nucleo si devono tenere in considerazione due esigenze contrastanti. Da un lato, i moduli di sistema più utilizzati dovrebbero essere inclusi nel kernel, dall'altro, il numero di moduli dovrebbe essere tale che la quantità di memoria occupata dal kernel non sia troppo grande. Oltre ai moduli software che fanno parte del kernel e si trovano permanentemente nella RAM, possono esserci molti altri moduli software di sistema chiamati transito. Transito moduli software caricato in RAM solo quando necessario e in assenza spazio libero può essere sostituito da altri moduli di transito.

3.) Il principio della generabilità del sistema operativo: L'essenza del principio consiste nell'organizzare (scegliere) tale metodo per la presentazione iniziale del programma di controllo del sistema centrale del sistema operativo (il kernel e i componenti principali permanentemente nella RAM), che ha permesso di personalizzare questa parte di supervisione del sistema in base alla configurazione specifica di un particolare complesso informatico e alla gamma di compiti da risolvere. Questa procedura viene raramente eseguita prima di un periodo di funzionamento sufficientemente lungo del sistema operativo. Il processo di generazione viene eseguito utilizzando uno speciale programma generatore e un linguaggio di input appropriato per questo programma, che consente di descrivere le capacità software del sistema e la configurazione della macchina. Il risultato della generazione è versione completa sistema operativo. La versione del sistema operativo generata è una raccolta di insiemi di sistema di moduli e dati.

4.) Principio di ridondanza funzionale: Questo principio tiene conto della possibilità di eseguire lo stesso lavoro con mezzi diversi. Il sistema operativo può includere diversi tipi di monitor (moduli supervisore che controllano l'uno o l'altro tipo di risorsa), vari mezzi per organizzare le comunicazioni tra i processi di elaborazione. La presenza di diversi tipi di monitor, diversi sistemi di gestione dei file consente agli utenti di adattare rapidamente e adeguatamente il sistema operativo a una configurazione specifica di un sistema informatico, per garantire il caricamento più efficiente dell'hardware durante la risoluzione di una specifica classe di problemi, per ottenere il massimo prestazioni nella risoluzione di una data classe di problemi.

5.) Principio di virtualizzazione: la costruzione di risorse virtuali, la loro distribuzione e utilizzo è attualmente utilizzata in quasi tutti i sistemi operativi. Questo principio consente di rappresentare la struttura del sistema sotto forma di un insieme specifico di pianificatori di processo e allocatori di risorse (monitor) e di utilizzare un unico schema di allocazione delle risorse centralizzato.

La manifestazione più naturale e completa del concetto di virtualità è il concetto macchina virtuale ... La macchina virtuale fornita all'utente riproduce l'architettura di una macchina reale, ma gli elementi architetturali in questa rappresentazione appaiono con caratteristiche nuove o migliorate, che, di regola, semplificano il lavoro con il sistema. Le caratteristiche possono essere arbitrarie, ma molto spesso gli utenti desiderano avere la propria macchina "ideale" in termini di caratteristiche architettoniche nella seguente composizione:

- memoria virtuale di volume praticamente illimitato, uniforme nelle logiche di funzionamento.

- un numero arbitrario di processori virtuali in grado di lavorare in parallelo e interagire durante il funzionamento.

- un numero arbitrario di dispositivi virtuali esterni in grado di lavorare con la memoria di una macchina virtuale in parallelo o sequenzialmente, in modo asincrono o sincrono rispetto al funzionamento di uno o dell'altro processore virtuale che avvia il funzionamento di tali dispositivi.

Uno degli aspetti della virtualizzazione è l'organizzazione della possibilità di eseguire applicazioni in un determinato sistema operativo, sviluppate per altri sistemi operativi. In altre parole, si tratta di organizzare più ambienti operativi.

6.) Il principio dell'indipendenza dei programmi da dispositivi esterni: questo principio è ora implementato nella stragrande maggioranza dei sistemi operativi generici. Per la prima volta, questo principio è stato implementato in modo più coerente nel sistema operativo UNIX. È anche implementato nella maggior parte dei moderni sistemi operativi per PC. Questo principio risiede nel fatto che la connessione di programmi con dispositivi specifici viene effettuata non a livello di trasmissione del programma, ma durante il periodo di pianificazione della sua esecuzione. Di conseguenza, la ricompilazione non è necessaria quando il programma è in esecuzione con un nuovo dispositivo su cui si trovano i dati.

7.) Principio di compatibilità: uno degli aspetti della compatibilità è la capacità del sistema operativo di eseguire programmi scritti per altri sistemi operativi o per versioni precedenti di questo sistema operativo, nonché per un'altra piattaforma hardware. È necessario separare le domande compatibilità binaria e compatibilità della sorgente applicazioni.

La compatibilità binaria si ottiene quando puoi prendere un programma eseguibile ed eseguirlo su un altro sistema operativo. Ciò richiede compatibilità a livello di istruzioni del processore e compatibilità a livello di chiamate di sistema e persino a livello di chiamate di libreria, se sono collegate dinamicamente.

La compatibilità della sorgente richiede un traduttore appropriato nel software di sistema, nonché la compatibilità delle librerie e delle chiamate di sistema. In questo caso è necessario ricompilare i testi sorgente esistenti in un nuovo modulo eseguibile.

È molto più difficile ottenere la compatibilità binaria tra processori basati su architetture diverse. Affinché un computer possa eseguire i programmi di un altro (ad esempio, è preferibile eseguire un programma per un PC come un PC IBM su un PC come un Apple Macintosh), questo computer deve funzionare con istruzioni macchina che inizialmente non comprendere. In questo caso, deve essere eseguito un processore 680x0 (o PowerPC) codice binario progettato per il processore i80x86. Il processore 80x86 ha il proprio decodificatore di istruzioni, registri e architettura interna. Il processore 680x0 non comprende il binario 80x86, quindi deve selezionare ciascun comando, decodificarlo per determinare se

cosa si intende fare, quindi eseguire la subroutine equivalente scritta per 680 × 0.

Uno dei mezzi per garantire la compatibilità del software e delle interfacce utente è la conformità agli standard POSIX, il cui utilizzo consente di creare programmi in stile UNIX facilmente trasferibili in seguito da un sistema all'altro.

8.) Il principio di apertura e scalabilità: Un sistema operativo aperto è disponibile per l'analisi sia dagli utenti che dagli specialisti di sistema che gestiscono il sistema informatico. Un sistema operativo espandibile (modificabile, sviluppato) consente non solo di utilizzare le capacità di generazione, ma anche di introdurre nuovi moduli nella sua composizione, migliorare quelli esistenti, ecc. In altre parole, dovrebbe essere possibile apportare facilmente aggiunte e modifiche, se necessario, senza compromettere l'integrità del sistema. L'approccio client-server alla strutturazione del sistema operativo utilizzando la tecnologia micronucleare offre eccellenti opportunità di espansione. In accordo con questo approccio, il sistema operativo è costruito come un insieme di programmi di controllo privilegiati e un insieme di servizi non privilegiati (server). La parte principale del sistema operativo rimane invariata e allo stesso tempo possono essere aggiunti nuovi server o migliorati quelli vecchi. Questo principio è talvolta interpretato come espandibilità del sistema.

9.) Principio di mobilità: il sistema operativo dovrebbe essere relativamente facile da trasportare

per connettersi da un tipo di processore a un altro tipo di processore e da una piattaforma hardware di un tipo, che include, insieme al tipo di processore e al modo di organizzare tutto l'hardware del computer (architettura del sistema informatico), a un altro tipo di piattaforma hardware . Si noti che il principio di portabilità è molto vicino al principio di compatibilità, sebbene non siano la stessa cosa. Scrivere un sistema operativo portatile è simile alla scrittura di qualsiasi codice portatile, ma è necessario seguirne alcuni regole:

- la maggior parte del sistema operativo deve essere eseguita in un linguaggio disponibile su tutti i sistemi su cui si prevede di portarlo in futuro. Questo, prima di tutto, significa che il sistema operativo deve essere scritto nella lingua alto livello, preferibilmente standardizzato, ad esempio in C. Un programma scritto in assembly non è generalmente portabile.

- è importante ridurre al minimo o, se possibile, escludere quelle parti di codice che interagiscono direttamente con l'hardware. La dipendenza dall'hardware può assumere molte forme. Alcune ovvie forme di dipendenza includono la manipolazione diretta di registri e altro hardware. Infine, se il codice dipendente dall'hardware non può essere completamente escluso, allora dovrebbe essere isolato in diversi moduli ben localizzati. Il codice dipendente dall'hardware non deve essere distribuito in tutto il sistema. Ad esempio, è possibile nascondere una struttura dipendente dall'hardware in un tipo di dati astratto programmabile.

L'introduzione degli standard POSIX era finalizzata a fornire la portabilità del software creato.

10.) Principio di sicurezza informatica: Garantire la sicurezza computazionale è una caratteristica desiderabile per qualsiasi sistema multiutente. Le regole di sicurezza definiscono proprietà come la protezione delle risorse di un utente da altre e l'impostazione delle quote di risorse per impedire a un utente di assumere tutte le risorse di sistema, come la memoria.

Garantire la protezione delle informazioni dall'accesso non autorizzato è una funzione obbligatoria dei sistemi operativi di rete.

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

Che cosaPOSIX: un'interfaccia di sistema indipendente dalla piattaforma per un ambiente informatico POSIX (Portable Operating System Interface for Computer Environments) è uno standard IEEE (Institute of Electrical and Electronics Engineers) che descrive le interfacce di sistema per sistemi operativi aperti, inclusi shell, utilità e toolkit. Inoltre, POSIX ha standardizzato le attività di sicurezza, le attività in tempo reale, i processi amministrativi, le funzioni di rete e l'elaborazione delle transazioni. Lo standard è basato su sistemi UNIX, ma può essere implementato anche in altri sistemi operativi. POSIX è nato come un tentativo in tutto il mondo organizzazione ben nota L'IEEE promuove la portabilità delle applicazioni negli ambienti UNIX sviluppando uno standard astratto e indipendente dalla piattaforma. Ad esempio, il noto sistema operativo in tempo reale QNX è conforme alle specifiche di questo standard.

Questo standard descrive in dettaglio il sistema di memoria virtuale VMS (Virtual Memory System), il multitasking MPE (Multi-Process Executing) e la tecnologia convergente prodotta da un sistema operativo (CTOS). Quindi, POSIX è in realtà un insieme di standard chiamato POSIX.I –POSIX.12. Va anche notato che POSIX.1 assume C come lingua principale.

Linguaggio di descrizione delle funzioni del sistema API.

Pertanto, i programmi scritti in conformità con questi standard verranno eseguiti in modo identico su tutti i sistemi conformi a POSIX. Tuttavia, in alcuni casi lo standard è solo di natura consultiva. Alcuni degli standard sono descritti in modo molto rigoroso, mentre l'altra parte rivela solo superficialmente i requisiti di base.

Le implementazioni del sistema operativo dell'API POSIX sono diverse. Se la stragrande maggioranza dei sistemi UNIX inizialmente è conforme alle specifiche IEEE Standard 1003.1-1990, WinAPI non è conforme a POSIX. Tuttavia, per supportare questo standard nel sistema operativo MS Windows NT, è stato introdotto uno speciale modulo di supporto API POSIX che opera a livello di privilegio dei processi utente.

Questo modulo fornisce la conversione e il trasferimento delle chiamate dal programma utente al kernel di sistema e viceversa, lavorando con il kernel tramite l'API Win. Altre applicazioni create utilizzando WinAPI possono passare informazioni alle applicazioni POSIX tramite meccanismi di flusso di I/O standard (stdin, stdout).

Nessun argomento correlato ...