Subiect: sisteme de operare.
Întrebare: nr. 8

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

Principii de proiectare a sistemului de operare:

1.) Principiul modularității– în cazul general, un modul este înțeles ca un element complet funcțional al sistemului, realizat în conformitate cu interfețele intermodulare acceptate. Prin definiția sa, un modul își asumă capacitatea de a-l înlocui cu ușurință cu altul dacă interfețele specificate sunt disponibile. În mare măsură, împărțirea sistemului în module este determinată de metoda de proiectare a sistemului de operare utilizată (de jos în sus sau invers).

De o importanță deosebită la construirea unui sistem de operare sunt modulele privilegiate, re-entrante și re-entrante (re-entry - literalmente re-entrant; termen special pentru a indica funcționalitatea programului; proprietatea unui program de a fi executat corect în timpul unui apel recursiv (returnat) dintr-o întrerupere).

Cel mai mare efect din utilizarea acestui principiu este realizabil dacă acest principiu este distribuit simultan către sistemul de operare, programele de aplicație și hardware.

2.) Principiul selectivității funcționale– sistemul de operare alocă o anumită parte a modulelor importante care trebuie să fie prezente în mod constant RAM pentru o organizare mai eficientă a procesului de calcul. Această parte a sistemului de operare se numește nucleu, deoarece este baza sistemului. La formarea compoziției miezului, trebuie luate în considerare două cerințe contradictorii. Pe de o parte, nucleul ar trebui să includă modulele de sistem cele mai frecvent utilizate, pe de altă parte, numărul de module trebuie să fie astfel încât cantitatea de memorie ocupată de nucleu să nu fie prea mare. În plus față de modulele de program care fac parte din kernel și sunt localizate permanent în RAM, pot exista multe alte programe de sistem modulele finale, care sunt numite tranzit. Modulele programului de tranzit sunt încărcate în RAM numai atunci când este necesar și, dacă nu există spațiu liber, pot fi înlocuite cu alte module de tranzit.

3.) Principiul de generare a sistemului de operare: Esența principiului este de a organiza (selecta) o astfel de metodă a reprezentării inițiale a programului de control al sistemului central al sistemului de operare (kernel-ul și principalele componente aflate permanent în RAM), ceea ce a făcut posibilă configurarea acestei părți de supraveghere a sistemului. pe baza configurației specifice a unui anumit complex de calcul și a gamei de sarcini rezolvate. Această procedură este rareori efectuată înainte de o perioadă destul de lungă de operare a sistemului de operare. Procesul de generare se desfășoară folosind un program generator special și limbajul de intrare corespunzător pentru acest program, care vă permite să descrieți capabilitățile software ale sistemului și configurația mașinii. Rezultatul generației este versiunea completă OS. Versiunea de SO generată este o colecție de seturi de sisteme de module și date.

4.) Principiul redundanței funcționale: Acest principiu ține cont de posibilitatea de a efectua aceeași muncă prin mijloace diferite. Sistemul de operare poate include mai multe tipuri de monitoare (module de supraveghere care gestionează unul sau altul tip de resursă), diverse mijloace de organizare a comunicațiilor între procesele de calcul. Prezența mai multor tipuri de monitoare și a mai multor sisteme de gestionare a fișierelor permite utilizatorilor să adapteze rapid și cel mai adecvat sistemul de operare la o anumită configurație a sistemului informatic, să asigure cea mai eficientă încărcare a hardware-ului atunci când rezolvă o anumită clasă de probleme și să obțină performanțe maxime la rezolvarea o anumită clasă de probleme.

5.) Principiul virtualizării: construcția resurselor virtuale, distribuția și utilizarea lor este utilizată în prezent în aproape orice sistem de operare. Acest principiu vă permite să prezentați structura sistemului sub forma unui anumit set de planificatori de procese și alocatoare de resurse (monitoare) și să utilizați o singură schemă centralizată pentru distribuirea resurselor.

Cea mai firească și completă manifestare a conceptului de virtualitate este conceptul mașină virtuală . Mașina virtuală oferită utilizatorului reproduce arhitectura mașinii reale, dar elementele arhitecturale din această reprezentare apar cu caracteristici noi sau îmbunătățite, simplificând de obicei lucrul cu sistemul. Caracteristicile pot fi arbitrare, dar cel mai adesea utilizatorii doresc să aibă propria mașină „ideală” în ceea ce privește caracteristicile arhitecturale, constând în următoarele:

— memorie virtuală de capacitate practic nelimitată, uniformă în logica de funcționare.

— un număr arbitrar de procesoare virtuale capabile să lucreze în paralel și să interacționeze în timpul funcționării.

— un număr arbitrar de dispozitive virtuale externe capabile să lucreze cu memoria unei mașini virtuale în paralel sau secvențial, asincron sau sincron în raport cu funcționarea unui anumit procesor virtual care inițiază funcționarea acestor dispozitive.

Unul dintre aspectele virtualizării este organizarea capacității de a rula aplicații pe un anumit sistem de operare care au fost dezvoltate pentru alte sisteme de operare. Cu alte cuvinte, vorbim despre organizarea mai multor medii de operare.

6.) Principiul independenței programului față de dispozitive externe: Acest principiu este acum implementat în marea majoritate a sistemelor de operare generale. Pentru prima dată, acest principiu a fost implementat cel mai constant în sistemul de operare UNIX. De asemenea, este implementat în majoritatea sistemelor de operare moderne pentru PC. Acest principiu este că conectarea programelor cu dispozitive specifice nu se desfășoară la nivelul difuzării programului, ci în perioada de planificare a executării acestuia. Ca urmare, recompilarea nu este necesară atunci când rulați programul pe un dispozitiv nou pe care se află datele.

7.) Principiul de compatibilitate: Un aspect al compatibilității este capacitatea sistemului de operare de a rula programe scrise pentru alte sisteme de operare sau pentru mai multe versiuni anterioare acest sistem de operare, precum și pentru alte platforme hardware. Este necesar să se separe întrebările compatibilitate binarăŞi compatibilitate la nivel de sursă aplicatii.

Compatibilitatea binară este obținută atunci când puteți lua un program executabil și îl puteți rula pe alt sistem de operare. Acest lucru necesită compatibilitate la nivelul instrucțiunilor procesorului și compatibilitate la nivel de apel de sistem și chiar la nivel de apel de bibliotecă dacă sunt legate dinamic.

Compatibilitatea la nivelul textului sursă necesită prezența unui traducător adecvat ca parte a sistemului software, precum și compatibilitatea la niveluri de bibliotecă și apel de sistem. În acest caz, este necesar să se recompileze textele sursă existente într-un nou modul executabil.

Este mult mai dificil să se realizeze compatibilitate binară între procesoare bazate pe arhitecturi diferite. Pentru ca un computer să execute programele altuia (de exemplu, un program pentru un computer, cum ar fi un computer IBM, ar trebui, de preferință, să fie executat pe un computer, cum ar fi un Apple Macintosh), acest computer trebuie să funcționeze cu instrucțiuni ale mașinii care sunt inițial de neînțeles. la el. În acest caz, un procesor 680x0 (sau PowerPC) trebuie să execute cod binar conceput pentru un procesor i80x86. Procesorul 80x86 are propriul decodor de instrucțiuni, registre și arhitectură internă. Un procesor 680x0 nu înțelege codul binar 80x86, așa că trebuie să preia fiecare instrucțiune și să o decodeze pentru a determina ce

ceea ce intenționează să facă și apoi executați rutina echivalentă scrisă pentru 680x0.

Unul dintre mijloacele de asigurare a compatibilității între software și interfețe cu utilizatorul este conformitatea cu standardele POSIX, a căror utilizare vă permite să creați programe în stil UNIX care pot fi transferate cu ușurință de la un sistem la altul.

8.) Principiul deschiderii și scalabilității: Un sistem de operare deschis este disponibil pentru analiză atât de către utilizatori, cât și de către specialiștii de sistem care întrețin sistemul informatic. Un sistem de operare extensibil (modificat, dezvoltat) vă permite nu numai să utilizați capabilități de generare, ci și să introduceți module noi în componența sa, să le îmbunătățiți pe cele existente etc. Cu alte cuvinte, ar trebui să fie posibil să se facă cu ușurință completări și modificări atunci când este necesar, fără a compromite integritatea sistemului. Oportunități excelente de extindere sunt oferite de abordarea client-server pentru structurarea sistemului de operare folosind tehnologia micro-kernel. În conformitate cu această abordare, sistemul de operare este construit ca un set de programe de control privilegiate și un set de servicii (servere) neprivilegiate. Partea principală a sistemului de operare rămâne neschimbată, în timp ce serverele noi pot fi adăugate sau cele vechi îmbunătățite. Acest principiu este uneori interpretat ca extinderea sistemului.

9.) Principiul mobilitatii: sistemul de operare ar trebui să fie relativ ușor de portat

transfer de la un procesor de un tip la un procesor de alt tip și de la o platformă hardware de un tip, care include, alături de tipul de procesor, metoda de organizare a întregului hardware de calculator (arhitectura sistemului de calcul), la o platformă hardware de alt tip. Rețineți că principiul portabilității este foarte apropiat de principiul compatibilității, deși nu sunt același lucru. Crearea unui sistem de operare portabil este similară cu scrierea oricărui cod portabil, dar trebuie să urmați unele reguli:

— cea mai mare parte a sistemului de operare trebuie să fie executată într-o limbă disponibilă pe toate sistemele către care este planificat să fie transferat în viitor. Acest lucru, în primul rând, înseamnă că sistemul de operare trebuie să fie scris în limba nivel înalt, de preferință standardizat, de exemplu în limbajul C Un program scris în limbaj de asamblare nu este în general portabil.

- Este important să minimizați sau, dacă este posibil, să eliminați acele părți ale codului care interacționează direct cu hardware-ul. Dependența de hardware poate lua mai multe forme. Unele forme evidente de dependență includ manipularea directă a registrelor și a altor hardware. În cele din urmă, dacă codul dependent de hardware nu poate fi eliminat complet, atunci acesta ar trebui izolat în mai multe module bine localizate. Codul dependent de hardware nu trebuie distribuit în întregul sistem. De exemplu, puteți ascunde o structură dependentă de dispozitiv în date definite de program de tip abstract.

Introducerea standardelor POSIX a fost menită să asigure portabilitatea software-ului creat.

10.) Principiul securității în calcul: asigurarea securității la efectuarea calculelor este o proprietate de dorit pentru orice sistem multi-utilizator. Regulile de securitate definesc proprietăți precum protejarea resurselor unui utilizator de alții și stabilirea cotelor de resurse pentru a împiedica un utilizator să preia toate resursele sistemului, cum ar fi memoria.

Asigurarea protecției informațiilor împotriva accesului neautorizat este o funcție obligatorie a sistemelor de operare în rețea.

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

Ce s-a întâmplatPOSIX: Interfață de sistem independentă de platformă pentru medii de computer POSIX (Portable Operating System Interface for Computer Environments) este un standard IEEE (Institute of Electrical and Electronics Engineers) care descrie interfețele de sistem pentru sisteme de operare deschise, inclusiv shell-uri, utilități și seturi de instrumente. În plus, conform POSIX, sarcinile de securitate, sarcinile în timp real, procesele administrative, funcțiile de rețea și procesarea tranzacțiilor sunt standardizate. Standardul se bazează pe sisteme UNIX, dar poate fi implementat și în alte sisteme de operare. POSIX a apărut ca o încercare a renumitului IEEE de a promova portabilitatea aplicațiilor în mediile UNIX prin dezvoltarea unui standard abstract, independent de platformă. De exemplu, binecunoscutul sistem de operare QNX în timp real respectă specificațiile acestui standard.

Acest standard descrie sistemul în detaliu memorie virtuală Tehnologia VMS (Virtual Memory System), MPE (Multi-Process Executing) și tehnologia CTOS (An Operating System produced Convergent Technology...) pentru transferul sistemelor de operare. Deci POSIX este de fapt un set de standarde numite POSIX.I prin POSIX.12. De asemenea, trebuie remarcat în mod special că POSIX.1 presupune C ca limbaj principal

limbaj pentru descrierea funcțiilor API-ului sistemului.

Astfel, programele scrise la aceste standarde vor rula la fel pe toate sistemele compatibile cu POSIX. Cu toate acestea, în unele cazuri, standardul este doar de natură consultativă. Unele dintre standarde sunt descrise foarte strict, în timp ce altele dezvăluie doar superficial cerințele de bază.

Implementări POSIX API la nivel sistem de operare sunt diferite. Dacă marea majoritate a sistemelor UNIX respectă inițial specificațiile IEEE Standard 1003.1-1990, atunci WinAPI nu este compatibil POSIX. Cu toate acestea, pentru a sprijini acest standard, sistemul de operare MS Windows NT a introdus un modul special de suport POSIX API care operează la nivelul de privilegiu al proceselor utilizatorului.

Acest modul oferă conversia și transmiterea apelurilor de la un program utilizator la nucleul de sistem și înapoi, lucrând cu nucleul prin API-ul Win. Alte aplicații construite folosind WinAPI pot transmite informații către aplicațiile POSIX prin mecanisme standard de flux I/O (stdin, stdout).

Nu există postări similare...

POSIX (Portable Operating System Interface for Computer Environments) este un standard IEEE (Institute of Electrical and Electronics Engineers) care descrie interfețele sistemului.

„În acest context, comenzile de sistem ar trebui să fie înțelese ca un anumit set de programe care vă permit să controlați procesele de calcul, de exemplu pstat, kill, dir etc.

Interfață POSIX__________________________________________________________ 305

fețe pentru sisteme de operare deschise, inclusiv shell-uri, utilitare și instrumente. În plus, conform POSIX, sarcinile de securitate, sarcinile în timp real, procesele administrative, funcțiile de rețea și procesarea tranzacțiilor sunt standardizate. Standardul se bazează pe sisteme UNIX, dar poate fi implementat și în alte sisteme de operare.

Interfața POSIX a început ca o încercare a IEEE de a promova portabilitatea aplicațiilor în mediile UNIX prin dezvoltarea unui standard abstract, independent de platformă. Cu toate acestea, POSIX nu se limitează la sistemele UNIX; Există diverse implementări ale acestui standard în sisteme care îndeplinesc cerințele standardului IEEE 1003.1-1990 (POSIX.1). De exemplu, binecunoscutul sistem de operare QNX real-time respectă specificațiile acestui standard, ceea ce facilitează portarea aplicațiilor către acest sistem, dar nu este un sistem UNIX sub nicio formă, deoarece arhitectura sa folosește principii complet diferite.

Acest standard detaliază tehnologia Virtual Memory System (VMS), Multiprocess Executing (MPE) și Portable Operating System (CTOS). Deci POSIX este de fapt multe standarde POSIX. 1-POSIX. 12. În tabel. 9.1 enumeră principalele domenii descrise de aceste standarde. De asemenea, trebuie remarcat în mod deosebit că în POSIX. 1 Se presupune că limbajul principal pentru descrierea funcțiilor API de sistem este C.

Tabelul 9.1. Familia de standarde POSIX

Standard ISO Standard Scurtă descriere

POSIX.0 Nu Introducere în standardul sistemelor deschise. Acest document

nu este un standard în forma sa pură, ci reprezintă recomandări și scurtă prezentare generală tehnologii

POSIX.1 Da System API (limbaj C)

POSIX.2 Fără shell și utilități (aprobat IEEE)

POSIX.3 Fără testare și verificare

POSIX.4 Fără sarcini în timp real și fire de execuție

POSIX.5 Da Se aplică limbajul ADA

la standardul POSIX. 1

POSIX.6 Fără securitate de sistem

POSIX.7 Fără administrare de sistem

POSIX.8 Fără rețea, acces transparent la fișier, rezumat

interfețe de rețea, independent de protocoalele fizice, apelurile RPC, comunicarea sistemului cu aplicații dependente de protocol

POSIX.9 Da Utilizarea limbajului Fortran, aplicabil

la standardul POSIX. 1

POSIX. 10 Fără profil de mediu de aplicație super-computing (AEP)

POSIX. 11 Fără procesare a tranzacțiilor AEP

POSIX. 12 Fără interfață grafică de utilizator (GUI)

306______________________________ Capitolul 9. Arhitectura sistemelor de operare

Astfel, programele scrise la aceste standarde vor rula la fel pe toate sistemele compatibile cu POSIX. Cu toate acestea, standardele sunt parțial doar de natură consultativă. Unele dintre standarde sunt descrise foarte strict, în timp ce altele dezvăluie doar superficial cerințele de bază. Adesea, sistemele software sunt declarate a fi compatibile cu POSIX, deși nu pot fi numite astfel. Motivele stau în abordarea formală a implementării interfeței POSIX în diferite sisteme de operare. În fig. Figura 9.1 prezintă o diagramă tipică de implementare pentru o aplicație strict compatibilă cu POSIX.

Orez. 9.1. Diagrama de implementare a unei aplicații strict conformă cu standardul POSIX

Figura arată că programul folosește doar biblioteci POSIX pentru a interacționa cu sistemul de operare. 1 și biblioteca standard C RTL, în care pot fi utilizate doar 110 de funcții diferite, descrise și de standardul POSIX. 1.

Din păcate, destul de des, pentru a crește performanța unui anumit subsistem sau pentru a introduce tehnologii proprietare care limitează domeniul de aplicare al aplicației la mediul de operare corespunzător, în timpul programării sunt utilizate și alte funcții care nu respectă standardul POSIX.

Implementările standardului POSIX la nivel de sistem de operare variază. În timp ce marea majoritate a sistemelor UNIX respectă inițial specificațiile IEEE Standard 1003.1-1990, atunci WinAPI nu este compatibil POSIX. Cu toate acestea, să-l sprijine în sala de operație sistem Windows NT a introdus un modul API special pentru a suporta standardul POSIX, operând la nivelul de privilegiu al proceselor utilizatorului. Acest modul oferă conversia și transmiterea apelurilor de la un program utilizator la nucleul de sistem și înapoi, lucrând cu nucleul prin WinAPI. Alte aplicații scrise folosind WinAPI pot transmite informații POSIX către aplicații prin mecanismele standard de flux I/O stdin și stdout.

Exemple de programare pentru diferite API-uri____________________ 307

Exemple de programare pentru diferite API-uri

Pentru a demonstra clar diferențele fundamentale dintre interfețele API ale celor mai populare sisteme de operare moderne pentru computere personale, să ne uităm la cel mai simplu exemplu, în care trebuie să numărați numărul de spații din fișiere text, ale căror nume trebuie specificate pe linia de comandă. Să luăm în considerare două versiuni ale programului: pentru Windows (folosind WinAPI) și pentru Linux (API POSIX).

Deoarece suntem interesați să lucrăm cu sarcini paralele, să presupunem că atunci când programul este executat, pentru fiecare dintre fișierele listate pe linia de comandă, este creat propriul său proces sau fir de execuție (sarcină), care, în paralel cu alte procese (file), efectuează munca de numărare a spațiilor în fișierul „său”. Rezultatul programului va fi o listă de fișiere cu numărul de spații numărate pentru fiecare.

O atenție deosebită trebuie acordată faptului că implementările de programe pentru rezolvarea acestei probleme prezentate mai jos nu sunt singurele posibile. Ambele sisteme de operare în cauză au metode diferite de lucru cu sistemul de fișiere și de gestionare a proceselor. ÎN în acest caz, este luată în considerare o singură opțiune, dar este cea mai tipică pentru interfața API corespunzătoare.

Pentru a face mai convenabilă compararea acestui program (Listing 9.1) cu următoarele (Listing 9.2) și, de asemenea, ținând cont de faptul că sarcina nu necesită o interfață fereastră pentru soluția sa, doar acele apeluri API care nu afectează interfața grafică sunt utilizate în text. Desigur, în zilele noastre este rar ca o aplicație să nu folosească capabilitățile GUI, dar în cazul nostru puteți vedea imediat diferența în organizarea funcționării paralele a calculelor lansate.

Alexey Fedorchuk
2005

Una dintre trăsăturile distinctive ale structurii logice a sistemului de fișiere al sistemelor de operare din familia POSIX este organizarea lor ierarhică, sau asemănătoare arborelui (deși, așa cum am spus deja, arborele arată puțin ciudat). Adică, nu există denumiri (de exemplu, alfabetice sau orice alta) pentru mediile individuale și secțiunile acestora, ca în DOS sau Windows de orice fel: toate sunt incluse într-o singură structură ca subdirectoare ale directorului principal. numită rădăcină. Procesul de conectare sisteme de fișiere pe medii fizice independente (și partițiile acestora) la rădăcina arborelui de fișiere se numește montare, iar subdirectoarele al căror conținut le cuprind sunt numite puncte de montare.

Din punct de vedere istoric, Unix a dezvoltat o anumită structură de directoare, foarte asemănătoare în termeni generali între diferiți membri ai acestei familii, dar ușor diferită în detalii. În special, ierarhia fișierelor în sistemele BSD este aproape identică, diferită de cea din Linux. Iar la acesta din urmă se constată diferențe semnificative între diferitele distribuții. Până la punctul în care structura ierarhiei fișierelor este una dintre caracteristicile specifice distribuției.

Această stare de fapt face dificilă scrierea de aplicații multiplatforme. Și, prin urmare, există și dezvoltă în mod activ un proiect de standardizare a ierarhiei de fișiere - FHS (Filesystem Hierarchy Standard).

Proiectul FHS a avut ca scop inițial simplificarea structurii de directoare a numeroase distribuții Linux. Mai târziu a fost adaptat pentru alte sisteme asemănătoare Unix (inclusiv clanul BSD). Și acum există eforturi active (dar nu foarte reușite) pentru a face din acesta un standard pentru sistemele POSIX, nu numai în nume, ci și în fapt.

Standardul FHS se bazează pe două principii fundamentale - o separare clară în ierarhia fișierelor a directoarelor partajate și nepartajate, pe de o parte, și imuabile și mutabile, pe de altă parte.

Contrastul dintre directoarele partajate și cele nepartajate se datorează naturii inerente în rețea a Unix. Adică, datele referitoare la mașina locală (de exemplu, fișierele de configurare pentru dispozitivele sale) ar trebui să fie situate în directoare separate de cele al căror conținut este accesibil de la alte mașini din rețea, locale sau globale (un exemplu din care nu este doar utilizatorul). date, dar și programe) .

Esența contrastului dintre directoarele imuabile și cele mutabile poate fi explicată cu ușurință printr-un exemplu. Astfel, aceleași programe generale de utilizator trebuie să fie de natură imuabilă (sau mai bine zis, disponibile pentru modificare doar administratorului de sistem, dar nu și utilizatorului însuși care le folosește în munca sa). În același timp, aceste programe, în timpul funcționării lor, generează nu numai fișiere de date, să zicem, texte sau imagini (natura lor variabilă este clară fără comentarii), ci și tot felul de informații de serviciu, cum ar fi fișiere jurnal, fișiere temporare și ca). Care ar trebui grupate în directoare separate de fișierele executabile efective de programe, biblioteci, fișiere de configurare etc., necesare lansării lor.

Cu toate acestea, în ciuda promovării active în multe dintre cele mai comune distribuții Linux, FHS nu a atins statutul de standard adevărat. Există multe distribuții Linux care nu folosesc unele dintre prevederile sale. Și se corelează doar parțial cu ierarhia tradițională de fișiere a sistemelor BSD.

Și motivul este că FHS ignoră un alt contrast care este foarte important pentru utilizator: contrastul dintre părțile ușor de recuperat ale sistemului de fișiere și cele ale componentelor sale care sunt greu de recuperat sau nu pot fi deloc recuperate.

Primul, destul de ciudat, include sistemul de bază în sine: la urma urmei, reinstalarea acestuia de pe mediul de distribuție în cazul unui accident fatal nu este atât de dificilă. Părțile greu de recuperat ale sistemului de fișiere includ, în mod evident, datele utilizatorului: chiar dacă se face backup în mod regulat (și câți utilizatori sunt atât de atenți?), derularea lor din arhive va dura mult timp (și aproape inevitabil va implica unele pierderi).

În plus, în sistemele BSD și distribuțiile Linux bazate pe sursă, aș clasifica drept directoare greu de restaurat tot ceea ce are legătură cu gestionarea pachetelor - arborele porturi FreeBSD sau pkgsrc în NetBSD (și sistemele care l-au împrumutat), analogii lor în distribuțiile Linux, sursele reale ale programelor portate, precum și codurile sursă ale sistemului. Pentru că, chiar dacă toate acestea sunt disponibile în kit-ul de distribuție, aceste componente ale sistemului de fișiere, de regulă, sunt ținute la zi de către utilizator prin sincronizarea prin Rețea cu serverele de proiect (altfel utilizarea lor este lipsită de sens). Iar pierderea lor va atrage atât pierderi temporare (mai ales cu o conexiune prin modem) cât și financiare (puțini oameni sunt fericiți proprietari ai accesului gratuit la Internet).

Respectarea strictă a conceptului de separare a directoarelor partajate și nepartajate, imuabile și imuabile, recuperabile și nerecuperabile unul de celălalt permite, în cadrul unei singure ierarhii de fișiere de tip arbore, să izolați fizic ramurile sale individuale - adică sub forma a sistemelor de fișiere independente situate pe dispozitive izolate (discuri, secțiuni de disc, slice, partiții etc.). Există multe motive pentru aceasta - creșterea vitezei, creșterea fiabilității și pur și simplu considerații de comoditate - dar nu vom vorbi despre ele acum. Pentru că în în acest moment Tot ceea ce contează pentru noi este că aceste ramuri ale arborelui de fișiere trebuie să fie încorporate în sistemul de fișiere general.

Un set tipic de directoare de sistem POSIX

De fapt, pentru funcționare este absolut necesar să existe un singur sistem de fișiere - cel care este montat în directorul rădăcină al arborelui de fișiere (un fel de analog al arborelui mondial Yggdrassil). Directorul rădăcină și ramurile sale esențiale trebuie să formeze un singur sistem de fișiere situat pe un singur mediu - un disc, o partiție de disc, o matrice RAID software sau hardware sau volum logic în sensul LVM. Și ar trebui să conțină toate componentele necesare pornirii sistemului și, în mod ideal, nimic mai mult.

Puteți vizualiza compoziția directorului rădăcină cu comanda

$ls -1/

care pe orice sistem POSIX va afișa un anumit set minim de directoare pentru gentleman:

Bin/ boot/ etc/ root/ sbin/

Acestea conțin toate fișierele fără de care sistemul nu poate exista. Alte directoare sunt cam așa:

Acasă/ mnt/ opt/ tmp/ usr/ var/

Ele a) nu sunt necesare (cel puțin teoretic - în practică este dificil să se facă fără ele), b) nu fiecare dintre ele este prezentă în toate sistemele și distribuțiile și c) fiecare dintre ele poate fi (și adesea este - dacă faci totul cu înțelepciune) ) punctul de montare al propriei sale ramuri a arborelui de fișiere.

În plus, în cele mai multe cazuri, în rădăcina sistemului de fișiere al sistemelor de operare compatibile cu POSIX există încă două subdirectoare:

Dev/proc/

Acestea sunt de obicei punctele de montare ale sistemelor de fișiere virtuale - dispozitive și respectiv procese (deși dacă sistemul de fișiere al dispozitivului nu este utilizat, directorul /dev trebuie să fie o componentă a sistemului de fișiere rădăcină. În sfârșit, pe sistemele Linux, de regulă , rădăcina arborelui de fișiere se află și un director /lib, destinat bibliotecilor principale de sistem Iar când se folosește mecanismul udev, este inevitabil și directorul /sys, în care este montat sistemul de fișiere virtual sysfs.

Sistem de fișiere rădăcină

Sistemul de fișiere rădăcină nu este partajat (adică nu este destinat partajarea diferite mașini din rețea) și neschimbabile (adică modificările pot fi făcute numai de administratorul de sistem, dar nu de programele utilizatorului și, mai ales, nu de utilizatori). Mai mult decât atât, nu este foarte recomandat să creați subdirectoare în el în afara celor prevăzute de standard (și enumerate mai sus).

Conținutul sistemului de fișiere rădăcină este selectat în așa fel încât mașina să poată porni și să păstreze funcționalitatea minimă chiar și în timpul unei porniri de urgență (sau în modul cu utilizator unic), când toate celelalte sisteme de fișiere nu sunt montate (și, în consecință, ramuri precum /usr sau /var pot să nu fie disponibile.

În conformitate cu aceasta, pornirea mașinii este asigurată de fișierele directorului /boot și /etc. Primul conține nucleul de sistem - un fișier executabil „cu scop special” - și tot ceea ce este necesar pentru a-l încărca: în Linux, de exemplu, aceasta este harta sistemului (fișier /etc/System.map), iar în FreeBSD - încărcabilă modulele nucleului. Cu toate acestea, uneori, nucleul este localizat direct la rădăcina sistemului de fișiere, iar apoi directorul /boot poate fi absent cu totul, iar directorul /modules poate fi alocat pentru modulele nucleului.

Directorul /etc este destinat fișierelor de configurare la nivel de sistem care determină condițiile de pornire. Conținutul său depinde foarte mult de sistem (și în Linux, de asemenea, de distribuție) și, prin urmare, nu îl voi lua în considerare aici - va trebui să revin la acest subiect de mai multe ori.

Funcționalitatea minimă necesară este asigurată de conținutul directoarelor /bin și /sbin - acestea conțin fișiere executabile ale celor mai importante programe de utilizator și de sistem, respectiv, chiar acelea care vă vor permite să efectuați un set de măsuri de reparare și salvare și readuceți mașina la forma umană după o defecțiune.

Distribuția programelor de sistem și utilizator în subdirectoarele rădăcinii este destul de arbitrară. Niciuna dintre aceste comenzi nu este cu adevărat destinată să rezolve problemele utilizatorilor. Doar că directorul /bin conține comenzi de administrare pe care un utilizator obișnuit le accesează (sau le poate accesa) din când în când, iar directorul sbin este destinat comenzilor despre care utilizatorul nu ar trebui să le cunoască. Și pe care, în cele mai multe cazuri, încă nu le va putea folosi din cauza lipsei permisiunilor adecvate (de exemplu, drepturile de acces necesare la fișierele dispozitivului).

Pentru a rula programe POSIX (inclusiv cele colectate în directoarele /bin și sbin), de regulă, aveți nevoie de acces la funcțiile bibliotecilor la nivel de sistem (în primul rând biblioteca glibc principală). Și prin urmare (aproape) o componentă indispensabilă a directorului rădăcină este subdirectorul /lib, în ​​care sunt colectate.

În Linux, directorul /lib servește un alt scop important - subdirectorul său (/lib/modules) conține module kernel încărcate (în FreeBSD locul lor este directorul /boot/kernel).

În FreeBSD, directorul /lib nu se găsește în sistemul de fișiere rădăcină - componentele corespunzătoare sunt localizate aici în /usr/lib (vezi mai jos). Acest lucru se datorează faptului că, din punct de vedere istoric, FreeBSD a construit programe critice la nivelul întregului sistem, astfel încât funcțiile de bibliotecă de care aveau nevoie să fie încorporate în executabilele lor (cunoscute sub numele de legături statice, discutate în Capitolul 14). În ramura 5 FreeBSD, programele din directoarele /bin și /sbin sunt legate dinamic, adică în absența directorului /usr (și în Free aceasta este aproape întotdeauna o ramură separată a sistemului de fișiere), nu funcționează . Pentru a compensa acest lucru, este furnizat un director non-standard /restore, care conține aceleași programe, dar legate static (după cum sugerează și numele directorului, singurul scop al conținutului său este munca de salvare de urgență).

Și în sfârșit /root . Acesta este directorul principal obișnuit al utilizatorului cu același nume, adică administratorul de sistem. Pentru că nu munca practica nu o face (sau cel puțin nu ar trebui), conținutul său este doar fișierele de configurare proprii ale superutilizatorului (shell-ul de comandă al utilizatorului, editorul preferat etc.).

Filiala /usr

Din punct de vedere istoric, directorul /usr era pentru programe și date utilizator. Aceste funcții sunt acum împărțite între directoarele /usr/local și /home (deși acesta din urmă este încă un link simbolic către /usr/home în mod implicit pe FreeBSD). Directorul /usr nu este modificabil, ci partajat și servește ca depozit pentru partea principală a programelor de aplicație și tot ceea ce se referă la acestea - coduri sursă, fișiere de configurare, biblioteci partajate, documentație și altele asemenea.

Compoziția directorului /usr diferă semnificativ între sistemele BSD și Linux. În prima, în el sunt plasate doar părți integrante ale sistemului de operare (ceea ce în FreeBSD este unit prin conceptul de Distribuții). Aplicațiile instalate din porturi sau pachete sunt înregistrate în subdirectorul /usr/local, care poate reprezenta o ramură separată a arborelui de fișiere.

În Linux, directorul /usr servește ca depozit pentru toate programele (și componentele acestora) care sunt incluse în mod standard în distribuție. Și subdirectorul /usr/local este de obicei destinat programelor care sunt compilate independent din surse.

În orice caz, compoziția obișnuită a directorului /usr este următoarea (ca rezultat din comanda ls -1):

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

După cum sa menționat deja, subdirectorul /usr/local este o ramură separată a arborelui de fișiere și, prin urmare, va fi luat în considerare separat. Scopul altor directoare este următorul:

• /usr/bin și /usr/sbin sunt destinate fișierelor executabile ale programelor utilizator și de sistem (aici granița dintre ele este chiar mai arbitrară decât în ​​cazul directorului rădăcină), al căror scop depășește asigurarea funcționării de bază a sistemul;
• /usr/etc este pentru fișierele de configurare ale aplicațiilor individuale;
• /usr/include conține așa-numitele fișiere antet necesare pentru legarea fișierelor executabile cu componentele bibliotecii;
• /usr/lib și /usr/libexec sunt directoare pentru bibliotecile partajate de care depind aplicațiile utilizatorului;
• /usr/share - un container pentru o mare varietate de așa-numite. componente independente din punct de vedere arhitectural: aici puteți vedea documentație în diferite formate, exemple de fișiere de configurare, date utilizate de programele de gestionare a consolei (fonturi, layout-uri de tastatură) și descrieri ale fusurilor orare;
• /usr/src - director pentru codurile sursă; în Linux, doar codurile sursă ale kernel-urilor de sistem sunt plasate în mod normal aici, în timp ce în clonele BSD - setul complet de coduri sursă ale complexului, care în FreeBSD se numește Distribuții; De regulă, nu este recomandabil să plasați aici codurile sursă ale programelor auto-asamblate;
• /usr/X11R6 - director pentru componentele sistemului de ferestre X - fișiere executabile (/usr/X11R6/bin), biblioteci (/usr/X11R6/lib), anteturi (/usr/X11R6/include), documentație (/usr/ X11R6/ om); Fișierele aplicației X nu trebuie plasate aici (cu posibilă excepție a managerilor de ferestre) - locul lor este în /usr, /usr/local sau /opt, în funcție de sistem.

În plus, directorul /usr poate conține subdirectoare /usr/var și /usr/tmp - de obicei link-uri simbolice către ramurile corespunzătoare ale directorului rădăcină. Și în unele distribuții Linux, documentația principală la nivel de sistem - paginile de manual (în subdirectorul /usr/man) sunt plasate direct în /usr.

În cele din urmă, pe sistemele BSD și unele distribuții Linux bazate pe sursă (de exemplu, Gentoo), directorul /usr conține un subdirector pentru sistemul de gestionare a pachetelor - porturile FreeBSD și OpenBSD (/usr/ports), analogii acestora pe alte sisteme (/usr /portage în Gentoo). Deși din punctul de vedere al respectării literei și spiritului standardului FHS (el însuși nu menționează un cuvânt despre porturi și sisteme similare), un loc mai logic pentru plasarea lor ar fi directorul /var (vezi mai jos) - și asta este exact ceea ce se face în distribuții precum CRUX și Archlinux.

Filiala /usr/local

După cum sa menționat deja, ramura /usr/local din Linux este destinată programelor care sunt compilate independent din codul sursă (nu sunt incluse în această distribuție). Și în FreeBSD, servește ca un container pentru majoritatea aplicațiilor utilizatorului - aproape tot ceea ce merge dincolo de distribuții și este instalat din pachete sau porturi. În consecință, structura directorului în ansamblu o urmează pe cea a ramurii /usr (cu excepții evidente):

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

Conținutul subdirectoarelor este, de asemenea, similar: fișiere de program executabile (/usr/local/bin și /usr/local/sbin), configurațiile acestora (/usr/local/etc), biblioteci cu care sunt legate și fișierele de antet ale acestora (/usr/ local/lib și, respectiv, /usr/local/include), pagini de manual (/usr/local/man) și tot felul de lucruri independente de arhitectură (/usr/local/share), inclusiv documentație în alte formate .

Sucursala /opt

Directorul /opt este furnizat de standardul FHS, dar nu este folosit de fapt în toate distribuțiile Linux și este complet absent pe sistemele BSD. Totuși, tot mai multe programe sunt scrise cu o instalare implicită în minte.

Din punct de vedere istoric, directorul /opt a fost destinat în Linux pentru aplicații comerciale și tot felul de programe de natură nu complet liberă. În zilele noastre, scopul său este să găzduiască complexe software auto-suficiente, precum biblioteca Qt, KDE cu toate componentele și aplicațiile sale, OpenOffice.org și altele asemenea. Structura directorului ar trebui să fie astfel: /opt/pkg_name. Iată cum arată pe sistemul meu (Archlinux):

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

Fiecare dintre subdirectoare are propria sa structură internă:

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

Scopul subdirectoarelor din /opt/pkg_name este ușor de ghicit prin analogie cu /usr și /usr/local. De exemplu, /opt/kde/bin este pentru fișierele executabile ale sistemului KDE și aplicațiile sale, /opt/kde/etc este pentru fișierele de configurare, /opt/kde/include este pentru fișierele antet, /opt/kde/lib este pentru biblioteci și /opt/kde/share - pentru fișiere partajate, inclusiv documentație. KDE nu are documentație în format man, dar dacă există, atunci (ca și în cazul lui Gnome - eu nu l-am instalat, așa au extras Gimp și aplicațiile similare Gtk) puteți vedea subdirectorul /opt/pkg_name/ omul .

Puteți vedea că structura directorului /opt se abate de la tradiția istorică (și justificată intern POSIX de a combina componente similare în directoare - fișiere executabile, biblioteci etc. Și cu un număr mare de programe instalate în el, creează anumite dificultăți : fie trebuie să supraîncărcați variabila cu valorile $PATH , care oferă acces rapid la comenzi (care vor fi discutate în Capitolul 12), fie să creați un director special /opt/bin și să plasați în el legături simbolice către programele binare executabile , într-o serie de distribuții Linux (de exemplu, în CRUX), directorul / opt nu este utilizat în principiu.

/var ramură

După cum sugerează și numele, directorul /var este destinat să stocheze fișiere mutabile generate în timpul funcționării normale a diferitelor programe - cache-uri software (de exemplu, browser), fișiere jurnal, spooling de imprimare și sisteme de e-mail, cutiile poştale, descrieri ale proceselor care rulează și așa mai departe. În special, în directorul /var sunt plasate așa-numitele dumpuri - instantanee ale stării RAM, generate în timpul unei opriri anormale pentru a identifica cauzele acesteia. O trăsătură distinctivă a tuturor acestor componente este caracterul lor schimbător în timpul unei sesiuni de lucru și faptul că acestea, totuși, trebuie păstrate atunci când sistemul este repornit.

Structura internă a /var variază foarte mult de la sistem la sistem și, prin urmare, nu mă voi opri asupra detaliilor structurii sale. Voi observa doar că acest director este un loc logic pentru plasarea componentelor tuturor tipurilor de sisteme de gestionare a pachetelor de tip port, așa cum se face, de exemplu, în distribuția Archlinux, unde îi este rezervat subdirectorul /var/abs (abs - Sistemul de clădire Archlinux).

Director /mnt

Directorul /mnt este destinat pentru montarea sistemelor de fișiere utilizate temporar, situate, de regulă, pe medii amovibile. Într-un sistem complet instalat, acesta este de obicei gol, iar structura sa nu este reglementată în niciun fel. Utilizatorul este liber să creeze subdirectoare în el pentru tipuri individuale de media. De exemplu, pe sistemul meu, acesta este /mnt/cd, /mnt/dvd, /mnt/usb și /mnt/hd - pentru CD-uri, DVD-uri, unități flash și hard disk-uri amovibile.

În FreeBSD, directoarele implicite pentru montarea CD-urilor și dischetelor sunt /cdrom și /floppy direct în directorul rădăcină. Ceea ce nu este în întregime în concordanță cu standardul, dar este logic în felul său - punctele de montare ale dispozitivelor care există (cum ar fi un CD ROM) sau au existat până de curând (o unitate de dischetă) în orice mașină sunt plasate în rădăcină.

Filiala /acasa

Directorul /home este destinat să conțină directoarele de acasă ale utilizatorilor. Conținutul său nu este reglementat în niciun fel, dar de obicei arată ca /home/(username1,...,username#) . Deși pe sisteme mari cu mulți utilizatori, directoarele lor de acasă pot fi grupate.

Directorul /home poate conține directoarele de acasă nu numai ale unor utilizatori reali, ci și ale unor utilizatori virtuali. Deci, dacă mașina este folosită ca server web sau ftp, puteți vedea subdirectoare precum /home/www sau, respectiv, /home/ftp.

Ramura /tmp

Singurul lucru despre care mai rămâne de vorbit este directorul pentru stocarea fișierelor temporare - /tmp. Ca și componentele /var, acestea sunt generate diverse programeîn cursul activităților lor normale de viață. Dar, spre deosebire de /var , componentele /tmp nu sunt de așteptat să fie salvate în afara sesiunii curente. Mai mult, toate manualele administrarea sistemului Este recomandat să curățați acest director în mod regulat (de exemplu, la repornirea mașinii) sau periodic. Și, prin urmare, ca /tmp, este recomandabil să montați sisteme de fișiere în RAM - tmpfs (în Linux) sau mfs (în FreeBSD). Pe lângă faptul că acest lucru asigură ștergerea conținutului său la repornire, îmbunătățește și performanța, de exemplu, compilarea programelor ale căror produse temporare nu sunt scrise pe disc, ci sunt plasate într-un director virtual precum /tmp/obj.

Pe multe sisteme veți vedea directoare precum /usr/tmp și /var/tmp. Acestea sunt de obicei link-uri simbolice către /tmp.

Strategia de partiționare a sistemului de fișiere

În încheierea conversației despre ierarhia fișierelor, trebuie subliniat faptul că este garantat că numai directoarele enumerate în paragraf ar trebui să fie localizate pe un singur sistem de fișiere (figurativ vorbind, pe o partiție de disc, deși acest lucru nu este complet corect) Sistem de fișiere rădăcină. Toate celelalte directoare - /usr, /opt, /var, /tmp și, desigur, /home pot reprezenta puncte de montare pentru sisteme de fișiere independente pe medii fizice separate sau partiții ale acestora.

Mai mult, în retea locala Aceste directoare pot fi localizate chiar și pe mașini diferite. Deci, un computer care acționează ca un server de aplicații poate conține directoarele /usr și /opt partajate în rețea, un altul - un server de fișiere - poate conține toate directoarele de acasă ale utilizatorilor și așa mai departe.

Tot ce rămâne este să decideți ce sisteme de fișiere sunt adecvate pentru a izola din arborele general de fișiere și de ce să faceți acest lucru. Răspunsul la aceste întrebări depinde foarte mult de sistemul de operare folosit, iar în cazul Linux, și de distribuția acestuia. Cu toate acestea, pot fi subliniate principiile generale pentru separarea sistemelor de fișiere. Din acest motiv, ar trebui să ne amintim contrastul dintre, pe de o parte, directoarele imuabile și mutabile și, pe de altă parte, datele ușor de recuperat, greu de recuperat și practic irecuperabile. Să facem această încercare în raport cu desktopul unui utilizator - în cazul unui server, calculele vor fi semnificativ diferite.

Evident, sistemul de fișiere rădăcină, constând din directoarele /bin, /boot, /etc, /root, /sbin, care conțin date care pot fi ușor restaurate de pe mediul de distribuție și sunt practic neschimbabile, ar trebui să fie situat pe o partiție de disc izolată. . Pe Linux, acesta ar trebui să includă și un director /lib. Pe de altă parte, atunci când utilizați GRUB ca bootloader (indiferent de sistemul de operare), este recomandat să plasați directorul /boot pe o partiție separată.

În sursele vechi despre Linux, puteți citi despre un alt motiv pentru alocarea unei partiții pentru directorul /boot și chiar la începutul discului: din cauza imposibilității de a încărca nucleul de către programul Lilo de la un număr de cilindru mai mare de 1023 . În versiunile moderne de încărcătoare nu există astfel de restricții. Cu toate acestea, dacă o partiție pentru /boot este deja creată, este rezonabil să o faceți prima de pe disc și să plasați partiția de swap direct în spatele acesteia: acest lucru va adăuga cinci cenți de performanță atunci când efectuați schimbul.

Și încă ceva din domeniul istoriei: cerința ca partițiile rădăcină și de boot să fie primare a fost, de asemenea, eliminată cu mult timp în urmă. Și aceste sisteme de fișiere se pot potrivi foarte bine pe partițiile logice din interiorul Partiției extinse.

Este la fel de clar că ramurile modificabile ale sistemului de fișiere - directoarele /var și /tmp - trebuie mutate în afara partiției rădăcină. Mai mult decât atât, acesta din urmă, așa cum s-a spus de multe ori înainte, este în general recomandabil să îl plasați pe un sistem de fișiere în RAM (tmpfs sau mfs). În cazul în care directorul /var conține subdirectoare pentru sisteme de gestionare a pachetelor de tip port, cum ar fi /var/abs , /var/cache/pacman/src și /var/cache/pacman/pkg în Archlinux, acestea ar trebui să formeze, de asemenea, sisteme de fișiere separate

Acum - directorul /usr, care conține fie componentele sistemului de bază (ca în BSD), fie cea mai mare parte a aplicațiilor utilizator (ca în majoritatea distribuțiilor Linux). Conține date ușor de recuperat și, pentru a fi corect, ar trebui să fie practic neschimbabil și, prin urmare, merită, desigur, să fie alocat într-o secțiune separată. Mai mult, din componența sa este indicat să se izoleze, pe de o parte, subdirectoarele /usr/X11R6 și /usr/local, pe de altă parte - subdirectoare pentru sistemele de gestionare a pachetelor de tip port: /usr/ports, /usr/pkgsrc și /usr/pkg în sistemele BSD, /usr/portages pe Gentoo Linux și așa mai departe. Mai mult, acestea din urmă ar trebui separate în subdirectoare pentru plasarea surselor descărcate din rețea atunci când construiesc porturi - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles și altele asemenea.

În sistemele BSD, în plus, din directorul /usr are sens să se selecteze subdirectoarele /usr/src și /usr/obj care conțin codul sursă al componentelor de bază (inclusiv nucleul) și produse intermediare ale compilației acestora, formate ca un rezultat al procedurilor make buildworld și make buildkernel .

Și, în sfârșit, directorul /home, care conține date modificabile și adesea irecuperabile, trebuie eliminat din rădăcina ierarhiei fișierelor. Mai mult, mereu încerc să-l plasez fie pe o felie separată (în BSD), fie pe partiția primară (în Linux).

Schema propusă pentru separarea sistemelor de fișiere poate părea complicată inutil. Cu toate acestea, garantează izolarea datelor ușor de recuperat, greu de recuperat și irecuperabile, ceea ce va facilita reinstalarea sistemului în caz de urgență și chiar migrarea de la sistem la sistem.

Avantajul său suplimentar este că pentru ramurile individuale ale arborelui de fișiere, în funcție de natura datelor aflate pe acesta, în Linux puteți selecta un sistem de fișiere optim din punct de vedere fizic. De exemplu, pentru partiția /boot nu are rost să folosiți altceva decât Ext2fs. De obicei, este recomandat să formatați partiția rădăcină în Ext3fs fiabil și compatibil. Pentru directoarele cu un număr mare de fișiere mici, cum ar fi /var/abs în Archlinux, /usr/portages în Gentoo, este recomandabil să utilizați ReiserFS: la urma urmei, profilul său este gestionarea abil a fișierelor mici. Și în directorul /home, unde pot apărea fișiere multimedia uriașe (și care în sine sunt de obicei foarte mari), XFS poate fi util (deși, așa cum arată măsurătorile, ReiserFS arată destul de decent aici). Astfel de măsuri pot ajuta la îmbunătățirea atât a fiabilității stocării datelor, cât și a vitezei operațiunilor cu fișierele.

Utilizatorii sistemelor de operare BSD sunt legați de sistemele de fișiere FFS fără alternativă. Cu toate acestea, au și spațiu de manevră. În primul rând, prin variarea dimensiunilor blocurilor și fragmentelor ale sistemelor de fișiere individuale, ceea ce contribuie fie la performanța operațiunilor pe disc, fie la economisirea spațiului pe disc. Și în al doilea rând, unele ramuri ale arborelui de fișiere (cum ar fi /tmp sau /usr/obj, contrar recomandărilor, pot fi montate în siguranță în modul pur asincron, câștigând un procent sau două în performanță.

- (IPAEng|ˈpɒzɪks) sau Interfața sistemului de operare portabil citează web | titlu = POSIX | url = http://standards.ieee.org/regauth/posix/ | munca = Standarde | publisher = IEEE] este numele colectiv al unei familii de standarde conexe specificate de IEEE ... Wikipedia

POSIX- este numele unei familii de standarde definite începând cu 1988 de Institutul de Ingineri Electrici și Electronici și desemnat formal IEEE 1003. Aceste standarde au apărut într-un proiect de standardizare des API des software destinate… …

Posix- este numele familiei de standarde definite începând cu 1988 de către IEEE și desemnat formal IEEE 1003.

POSIX- este acronimul Portable Operating System Interface; la X vine de UNIX ca seña de identitate a API. El término a fost sugerat de Richard Stallman în răspuns la cererea IEEE, căutând un nume ușor de amintit. Una traducere... Wikipedia Español

POSIX- , 1986 în Standard 1003.1 der IEEE niedergelegte Spezifikation für Zugriffe auf Systemfunktionen sub Unix. Sowohl Unix Sy... Universal-Lexikon

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

POSIX- este acronimul Portable Operating System Interface, vinând X de UNIX cu semnificația API-ului (Se traduce ca Sistem Operativo Portable bazat în UNIX). Acestea sunt o familie de standarde de apeluri la sistem… … Enciclopedia Universal

POSIX- (Interfață de sistem de operare portabilă bazată pe uniX) n. colecție de standarde pentru sistemele de operare care se bazează pe Unix (calculatoare) ... Dicționar englez contemporan

POSIX

Posix- Das Portable Operating System Interface (POSIX [ˈpɒsɪks]) este o interfață compatibilă cu IEEE și der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Application und dem… … Deutsch Wikipedia

Cărți

• , Stephen A. Rago, W. Richard Stevens. „UNIX. Programare profesională” este un ghid de referință detaliat care de 20 de ani ajută programatorii profesioniști C să scrie exclusiv...
• UNIX. Programare profesională de Stevens W. Richard, Rago Steven A. Această carte este foarte populară printre programatorii serioși din întreaga lume, deoarece conține cele mai importante și practice informații despre gestionarea nucleelor ​​UNIX și Linux. Fara acestea...

Cursul acoperă standardul de interfață a sistemului de operare mobil (POSIX), precum și tehnici și metode de programare a aplicațiilor bazate pe acest standard, explicate cu numeroase exemple. Sunt abordate problemele de programare a sistemelor multiproces și interacțiunea aplicațiilor în cadrul configurațiilor distribuite. Asigurarea mobilității (portabilitatea) software-ului este o sarcină de o importanță și complexitate excepționale; în vremea noastră, această circumstanță nu are nevoie de o justificare extinsă. La nivelul serviciilor de sistem, un astfel de mediu este descris de standardul POSIX (Portable Operating System Interface - interfata sistemului de operare mobil); Numele a fost sugerat de celebrul specialist, fondator al Free Software Foundation, Richard Stallman.

Cursul examinează versiunea sa cea mai modernă, modificată în 2003, care poate fi numită „standard triplu”, și anume: standardul IEEE Std 1003.1, Standardul tehnic Open Group și, cel mai important pentru noi, standardul internațional ISO/IEC 9945. Sarcina principală Acest curs este despre înțelegerea tehnicilor și metodelor de utilizare a utilităților și funcțiilor standardizate. Scopul a fost să nu repovesti standardul, evidențiind toate subtilitățile implementării OS, toate codurile de eroare posibile etc. Principalul lucru, în opinia noastră, este să simțim spiritul standardului și să învățăm să folosim capabilitățile inerente acestuia într-un mod mobil. Presupunând că cititorul vorbește C, nu am luat în considerare nici funcțiile de sintaxă, nici de bibliotecă de manuale. În ceea ce privește limbajul standard de comandă și interpretul acestuia, acest subiect este prezentat în detaliu, deși mulți programatori practicanți preferă să folosească alți interpreți. Un loc semnificativ - atât ca volum, cât și ca rol - este dedicat exemplelor de programe. Multe prevederi ale standardului (legate, să zicem, de gestionarea situațiilor de eroare) sunt expuse nu în textul principal, ci în exemplele corespunzătoare Acestea din urmă, ori de câte ori a fost posibil, au fost compilate și executate pe mai multe platforme hardware și software care, la una grad sau altul, pretind că respectă standardul POSIX. Cu toate acestea, sunt desigur posibile omiteri. Vom fi recunoscători pentru toate comentariile și sugestiile legate atât de cursul ca întreg, cât și de exemplele de programe individuale.

Istoricul creării și starea actuală a standardului POSIX.

Asigurarea mobilității (portabilitatea) software-ului este o sarcină de o importanță și complexitate excepționale; în vremea noastră, această împrejurare nu are nevoie de o justificare extinsă. Una dintre modalitățile general acceptate de a crește portabilitatea software-ului este standardizarea mediului de aplicație: interfețe software furnizate, utilități etc. La nivelul serviciilor de sistem, un astfel de mediu este descris de standardul POSIX (Portable Operating System Interface - interfața sistemului de operare mobil); Numele a fost propus de celebrul specialist, fondator al Free Software Foundation, Richard Stallman.

Pagina de titlu.
Date de ieșire.
Curs 1. Concepte și idei de bază ale standardului POSIX.
Curs 2. Limbajul Shell.
Cursul 3. Utilități și funcții care servesc conceptului de „utilizator”.
Curs 4. Organizarea sistemului de fișiere.
Curs 5. Intrare/ieșire fișier.
Curs 6. Instrumente pentru prelucrarea datelor structurate.
Curs 7. Procese.
Curs 8. Instrumente de comunicare interprocese.
Cursul 9. Interfață terminală comună.
Cursul 10. Supravegherea caracteristicilor gazdei și utilizarea lor în aplicații.
Curs 11. Instrumente de rețea.
Cursul 12. Timpul și lucrul cu el.
Curs 13. Mediu lingvistic și cultural.
Curs 14. Concluzie.
Referințe.

Descărcare gratuită e-carteîntr-un format convenabil, urmăriți și citiți:
Descărcați cartea Programare în standardul POSIX, partea 1, Galatenko V.A., 2016 - fileskachat.com, descărcare rapidă și gratuită.